Skip to content

Conversation

@filbranden
Copy link
Member

@mbiebl @zonque @mezcalero

I'm fairly happy with this patch set and I'm fairly confident it fixes most of the recent quoting/escaping regressions.

The commit description indicates differences from previous versions, for instance handling of ; and ; is more strict now, please confirm you're OK with those changes.

Cheers,
Filipe

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I need a log_*_errno here? Other places in this function will log, and I also have return log_oom() elsewhere... What would be an appropriate log for places where I'm returning -EINVAL or similar errors from unquote_first_word?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think that would help users to spot problems in their unit files. Just use log_syntax(), as that will already include the current line and file that is parsed, and augment that with whatever caused the error (in this case, 'p').

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Using log_syntax() for errors from unquote_first_word() and using log_oom() if some strv operation fails (this is a pattern I've also seen elsewhere.)

@filbranden filbranden force-pushed the unquote_first_word1 branch from bab7886 to c34e9e6 Compare June 4, 2015 01:35
@filbranden
Copy link
Member Author

I updated the commit to:

  • Rebase to latest sources, including upstream fix for escaping of semicolon as \073
  • Added additional test cases, especially around handling of semicolon, both on its own, escaped and quoted.
  • Added logging to all code paths that return an error.
  • Kept original behavior of returning 0 instead of -EINVAL on failure of unquoting (e.g. unbalanced quotes, etc.)

I think this one is ready to go. Would you please take another look? Let me know if there's anything that needs to be addressed (or feel free to take over, download the pull request and do small changes before you push it.)

Cheers,
Filipe

@filbranden
Copy link
Member Author

cc @arvidjaar who commented on this patchset before.

@filbranden
Copy link
Member Author

Thanks for your comments!

I'd appreciate it if you could answer my questions above. I'll try to send you an updated patchset over the weekend.

Cheers,
Filipe

@filbranden filbranden force-pushed the unquote_first_word1 branch from c34e9e6 to a475d28 Compare June 9, 2015 16:00
@filbranden
Copy link
Member Author

Updated according to the comments and added a lot more tests.

Also split the new tests into a separate prequel commit, so that the behavior changes would be very explicit in the changes to the test results.

Tested it to make sure make check is still working as expected and also installed and booted with it, didn't see any problems.

Please take another look.

Cheers,
Filipe

@poettering
Copy link
Member

Unfortunately it doesn't apply anymore! Sorry for the long delay in reviewing. Any chance you can rebase this? Will merge then!

@filbranden
Copy link
Member Author

I'll rebase and retest today...

Or if you prefer to delay this until after v221 release just let me know and I'll postpone it.

Ok to reuse the same PR? I guess as there are no line comments really then it should be fine...

If I don't hear from you again about postponing for after v221, then expect rebased and retested later today from me.

Cheers,
Filipe

@poettering
Copy link
Member

sounds good to merge this before the release. it has tests and stuff after all. reusing the PR is fine, though usually we rty to avoid it...

@poettering poettering added this to the v221 milestone Jun 17, 2015
@martinpitt
Copy link
Contributor

I don't want to make a big fuss, but we've had way more than just one regression due to parser changes in the past, including really bad ones which crashed pid 1. Usually stuff like that isn't the best thing to land two days before making a new release..

@filbranden
Copy link
Member Author

@martinpitt Yeah I kind of agree with you... I'll leave the final decision to @poettering though, so I think I'll rebase and push and then this can be merged either before or after v221 (I don't expect it to get out of sync between now and then.)

If you prefer to only merge parts of it now (such as the extra unit tests) I'd be happy to move only those commits that do not change behavior to another PR so that it can be merged now (or feel free to just check out this PR branch and cherry-pick them yourself.)

Cheers!
Filipe

@poettering
Copy link
Member

There are two days left, and it's the days where people probably test the most, hence please go ahead with the full patch set.

The new flag UNQUOTE_UNESCAPE_RELAX preserves unrecognized escape
sequences verbatim in unquote_first_word, either when it's a trailing
backslash (similar to UNQUOTE_RELAX, but in this case keep the extra
backslash in the output) or in the middle of a sequence string.

Add unit test cases to ensure the new flag works as expected and to
prevent regressions from being introduced.

Tested with a follow up commit converting config_parse_exec() to start
using unquote_first_word, in which case this flags makes it possible to
preserve unrecognized escape sequences.

Relevant bug: https://bugs.freedesktop.org/show_bug.cgi?id=90794
It will try to unquot_first_word, but if it runs into escaping problems
it will retry it adding UNQUOTE_CUNESCAPE_RELAX to the flags.  If it
succeeds on the second try, it will log a warning about it.  If it fails
both times, it will log an error.

Add test cases to confirm it behaves as expected.
These tests will be useful to check the cases regarding quoted and
escaped semicolon when we switch to using unquote_first_word.

Additionally, convert some of the tests that have semicolons so that the
argument after the semicolon looks like a path (starts with /) so that
we can see the change of behavior when making config_parse_exec more
strict about what it accepts as a command separator.
Convert config_parse_exec() from using FOREACH_WORD_QUOTED into a loop
of unquote_first_word.

Loop through the arguments only once (the FOREACH_WORD_QUOTED
implementation did it twice, once to count them and another time to
process and store them.)

Use newly introduced flag UNQUOTE_UNESCAPE_RELAX to preserve
unrecognized escape sequences such as regexps matches such as "\w",
"\d", etc. (Valid escape sequences such as "\s" or "\b" still need an
extra backslash if literals are desired for regexps.)

Differences in behavior:

- Handle ; (command separator) in special, so that only ; on its own is
  valid for that purpose, an quoted semicolon ";" or ';' will now behave
  as a literal semicolon.  This is probably what was initially intended.

- Handle \; (to introduce a literal semicolon) in special, so that only \;
  is turned into a semicolon but not \\; or "\\;" or "\;" which are kept
  as a literal \; in the output.  This is probably what was initially
  intended.

Known issues:

- Using an empty string (for example, ExecStartPre=<empty>) will empty
  the list and remove the existing commands, but using whitespace only
  (for example, ExecStartPre=<spaces>) will not.  This is a pre-existing
  issue and will be dealt with in a follow up commit.

Tested:

- Unit tests passing.  Also `make distcheck` still works as expected.

- Installed it on a local machine and booted with it, checked console
  output, systemctl and journalctl output, did not notice any issues
  running the patched systemd binaries.

Relevant bug: https://bugs.freedesktop.org/show_bug.cgi?id=90794
…pace

This is consistent with how an empty string works in an ExecStart=
statement.  We should not differentiate between an empty string and
whitespace only (since they look the same.)

Update the test case with whitespace only to reflect that the list is
reset.

Tested that `test-unit-file` passes and other test cases are not
affected.  Installed the patched systemd binaries on a machine, booted
it, looked for out of the usual behavior but did not find any.
@filbranden filbranden force-pushed the unquote_first_word1 branch from a475d28 to c83f1f3 Compare June 17, 2015 18:35
@filbranden
Copy link
Member Author

Rebased (no conflicts, git did all the job by itself), retested with unit tests, also installed it and booted my machine with it, looked at output of journalctl and systemctl and everything looks sane.

So I'd say it's good to go.

Cheers,
Filipe

poettering added a commit that referenced this pull request Jun 17, 2015
Replace FOREACH_WORD_QUOTED with a loop using unquote_first_word in config_parse_exec()
@poettering poettering merged commit 7391cb5 into systemd:master Jun 17, 2015
@filbranden
Copy link
Member Author

Awesome thanks!

@martinpitt Let me know if you find any regressions, hopefully the test coverage is enough to prove this works as supposed to and the minor changes in behavior of corner cases shouldn't really affect any real use cases.

@filbranden filbranden deleted the unquote_first_word1 branch June 17, 2015 18:44
@martinpitt
Copy link
Contributor

FTR, I turned the crank on my "build packages from upstream trunk" machinery again, and it passed both our integration tests as well as a manual one on a standard desktop install. We don't use any "fancy" Exec* statements there, but at least any potential regression shouldn't be so bad that we break the boot or anything. Sorry, I'm maybe just being a bit over-cautious after the previous trouble :-)

@filbranden
Copy link
Member Author

@martinpitt Totally understandable.

On the other hand, at one point or another this will end up hitting distros and that's when we're likely to find any problems, so whether it would be v221 or v222 doesn't seem to matter that much... Probably better to push it earlier since then we figure out if there's a problem earlier and deal with it, possibly in time to provide distros with a nice backport to fix it downstream.

Cheers!
Filipe

@poettering
Copy link
Member

@martinpitt thanks a lot! of course best would be to make that machinery run continously! the more CI the merrier! And we'll promise from upstream to look at it all the time.

@martinpitt
Copy link
Contributor

@poettering: absolutely. Right now I run it on my laptop daily, and upload the generated packages to https://launchpad.net/~pitti/+archive/ubuntu/systemd (this will only get packages whose tests succeeded). So other users can easily try trunk.

This surely ought to run in some cloud instances, I'm working on that. But this might still be a few weeks, this is much more demanding than a make check as the integration tests wreck the testbed in various ways, reboot it dozens of times, etc. We do that with distro packages, but we don't yet have the machinery to run it on PPAs.

whot pushed a commit to whot/systemd that referenced this pull request Oct 10, 2017
iaguis pushed a commit to kinvolk/systemd that referenced this pull request Feb 6, 2018
networkd: make sure we remove udev fd from epoll *before* closing it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

4 participants