udev-rules: fix matching of token types that support alternative patterns#26886
udev-rules: fix matching of token types that support alternative patterns#26886yuwata merged 3 commits intosystemd:mainfrom
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
How the example was parsed previously? |
The value of |
Oh,,, terrible... |
yuwata
left a comment
There was a problem hiding this comment.
LGTM. But please extend the commit message of the first commit.
…erns
For those token types that support matching of alternative patterns,
their token values are interpreted as nulstr, so make sure the parser
does the right thing and makes these token values terminated by two
subsequent NULs so they could be safely interpreted as nulstr.
Before this fix, the following rules would result to "echo foo" invocation:
ENV{foo}=", RUN"
ENV{foo}=="bar", RUN+="echo foo"
because the value of `ENV{foo}` is treated as nulstr, and it used to match
against alternative patterns, in this case `bar`, `, RUN`, and `="echo foo`.
Fixes: 25de7aa ("udev: modernize udev-rules.c")
This reverts commit cd3c8a1 which was papering over the bug instead of a proper fix made by the previous commit.
Fix check for conflicting and duplicate expressions of types that support alternative patterns. Fixes: 3ec58d0 ("udev-rules: check for conflicting and duplicate expressions")
Done, please take a look. |
|
From the commit message:
Maybe, "+" is mistakenly inserted? |
|
btw, this might obsolete commit cd3c8a1 which seems to paper over this bug. |
Indeed. Yeah, I agree. Feel free to revert it. |
It was a typo, fixed, thanks! |
Added a revert commit to this series. |
|
The first two commits backported to v253-stable. I assume the last one is not needed. |
|
This seems to have caused a regression, see @ldv-alt can you please take a look? |
|
Thanks @yuwata . |
|
Even if you are not sure, opening issue is fine. Especially, when the issue is in such a core part of systemd. |
For those token types that support matching of alternative patterns,
their token values are interpreted as nulstr, so make sure the parser
does the right thing and makes these token values terminated by two
subsequent NULs so they could be safely interpreted as nulstr.
Before this fix, the following rules would result to "echo foo" invocation:
because the value of
ENV{foo}is treated as nulstr, and it used to matchagainst alternative patterns, in this case
bar,, RUN, and="echo foo.