Description of problem: systemd-udevd attemps the command /usr/bin/setfacl -m g:lirc:rw multiple times every day and it fails with exit code 2, which is undocumented. Version-Release number of selected component (if applicable): systemd-udev-229-9.fc24.x86_64 How reproducible: for weeks now since I started checking logs more carefully Steps to Reproduce: 1. I have no idea what causes this command to run. Actual results: Error Expected results: No error
Please, provide output of 'journalctl -b' when this happens.
Created attachment 1188891 [details] boot messagses Here is everything up to the instance of these (many) errors. If you need more, let me know.
systemd-udevd[1100]: Process '/usr/bin/setfacl -m g:lirc:rw ' failed with exit code 2. It is apparently missing an argument, the path. The command is likely triggered by the udev rule shipped in lirc-core: KERNEL=="lirc[0-9]*", SUBSYSTEM=="lirc", GROUP="lirc", MODE="0660" ACTION=="add", SUBSYSTEM=="usb", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}" Could you please also attach output of 'udevadm info -e'?
Created attachment 1189784 [details] requested output Again, lots of data. You're welcome to nearly all of it, but it would be appreciated if you let me know what bits you need.
There should be at least one block in the udevadm output with SUBSYSTEM=lirc and a DEVNAME with "lirc" in it. I can't see either. Do you have a plugable infrared device? Do you use any infrared device at all? I don't have any hardware where I could attempt to reproduce this.
Interesting. I don't use any IR devices. That's like bar-code readers and remote control interfaces, right? Maybe there is support on my mainboard for something. Either way, I'm sure it's not installed...no I don't see anything in the manual. Sorry, I'm not sure what it could be. Let me know if I can query something else for you. I appreciate your help!
Oh wait, I *can* reproduce this even without any IR device! It's enough to have lirc-core installed and boot. That's really weird, I'll look into this.
I now see what's going on, I missed this when I wrote comment 3. The udev rule looks like this: $ cat /usr/lib/udev/rules.d/60-lirc.rules # Installing this udev rule will make the /dev/lirc* devices accessible # for users in the group "lirc" using regular group permissions. USB # devices grants rw permission to the lirc group using ACL. # To enable, copy to /etc/udev/rules.d. KERNEL=="lirc[0-9]*", SUBSYSTEM=="lirc", GROUP="lirc", MODE="0660" ACTION=="add", SUBSYSTEM=="usb", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}" There is *no continuation* between the first and second line! As a result, the rule makes *every* usb device writable by the lirc group, which is definitely not the desired result.
Oops... Noted, will fix.
Too quick, sorry. These are actually two rules, and there should not be any continuation line. The first is about the /dev/lirc[0-9] devices which feels safe to assign to the lirc group. The second is an attempt to give the lirc group access to usb hardware without breaking too many eggs i.e., without meddling with the group ownership. The problem seems to be that $env{DEVNAME} is empty for you, and I frankly have no idea as to why. Some simple googling doesn't give me anything. If noone else has an idea, I might have to resort to evil shell code disabling the call when env{devname} is empty. Is an empty env{devname} OK from udev point of view?
hm... If you make a test replacing ACTION=="add", SUBSYSTEM=="usb", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}" with ACTION=="add", SUBSYSTEM=="usb", ENV{DEVNAME}!="", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}" Does it fix this problem?
Okay, it's in place. Good idea. I'll let you know what happens in a couple days, as I do not know how to trigger this event and have to wait and see what I get on the next few log reports.
Well, DEVNAME doesn't have to be there for all usb devices. The second part of the rule matches all "add" rules for all usb devices, which means basically every usb device that gets plugged in. I'm not sure what you are trying to achieve... If I understand it correctly, you want to add all IR devices to "lirc" group, is that correct? In that case, you don't need the second part of the rule.
(In reply to Alec Leamas from comment #11) > > ACTION=="add", SUBSYSTEM=="usb", ENV{DEVNAME}!="", \ > RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}" > > Does it fix this problem? No, this will just hide it. Unrelated usb devices can still match if they happen to have a DEVNAME.
I actually intend to match all usb devices. Generally, anything can be used as a IR receiver, there is no simple match for that. OTOH, this is *not* changing the group, that would be far to invasive. This rule is using extended ACLs to give users in the lirc group access without changing the devices' group (or anything else in the basic ownership/permissions set) So, if there is a problem hidden here it is that usb devices without a DEVNAME will not be accessible for the lirc group. No idea if and possibly how this should be coped with. One possible enhancement might be to package this rule in a separate subpackage, making it a little more visible. lirc already does so with another rule which is *really* invasive (it blocks the kernel decoding). But, IMHO it's not really necessary in this case. Giving a system user like lirc this kind of access seems reasonable in a system installing lirc (typically a HTPC box).
(In reply to Alec Leamas from comment #15) > I actually intend to match all usb devices. Generally, anything can be used > as a IR receiver, there is no simple match for that. Are you sure that IR devices don't identify themselves as IR devices? I would try but don't have such hardware. > OTOH, this is *not* changing the group, that would be far to invasive. This > rule is using extended ACLs to give users in the lirc group access without > changing the devices' group (or anything else in the basic > ownership/permissions set) The problem is that you are also giving the users from the lirc group rw access to all keyboards, mouses, usb hubs, ... Which might be considered a CVE if we are paranoid enough. > So, if there is a problem hidden here it is that usb devices without a > DEVNAME will not be accessible for the lirc group. No idea if and possibly > how this should be coped with. Not every usb device is represented by a node in /dev (from my observation, usb hubs seem to be such case), hence no DEVNAME. If you have some hardware, you can try: 1) Run 'udevadm monitor -u -p' in a terminal. 2) Plug in the device. 3) Observe the output from 1). My guess is there would be something that could be used to identify the IR device almost every time. > One possible enhancement might be to package this rule in a separate > subpackage, making it a little more visible. lirc already does so with > another rule which is *really* invasive (it blocks the kernel decoding). > But, IMHO it's not really necessary in this case. Giving a system user like > lirc this kind of access seems reasonable in a system installing lirc > (typically a HTPC box). I agree that a subpackage is unnecessary. I disagree on the access rights, see above.
The point is that lirc is capable of using generic devices such as fdti, arduino and similar hardware as IR input. Add to that a large number of IR devices with bundled capture hardware identified as keyboards. So, to maintain that list is just not feasible. lirc is really about being able to use just about anything. Bottom line: there ain't such a thing as "IR device" from a usb/udev perspective
BTW: This discussion is off-topic seen from the bug. Paul's problem is the log messages, and the related udev errors and we shouldn't hijack his bug for this discussion. Please file a new bug about "to broad permission in lirc rule" if you feel strongly about this.
I don't have much to contribute here, but the problem I'm reporting is that systemd-udevd threw an error. If you choose to treat this report as a logging enhancement request, that's your prerogative. It sounds like I just don't need lirc. Thanks for explaining; reading the error I had no idea this wasn't something generic and internal to udev. I did not install it, deliberately, and I don't remember what I installed that required it. I'll let you know, tomorrow, if that change prevented the errors. Then I'll uninstall LIRC and you can do whatever you want with this...unless you want my help since I seem to have some devices for which DEVNAME is never set. If so, just let me know. I'm happy to do that.
Aug 16 20:17:41 <hostname> systemd-udevd[7767]: Process '/usr/bin/setfacl -m g:lirc:rw ' failed with exit code 2. No joy. I assume I didn't have to restart anything, right? I checked and the rule is still modified as you requested; it didn't get reset somehow. But, I didn't reboot. Let me know if I have implemented your test, properly. I also think I know what is the device in question: yubikey. Judging by the time stamps, I'm almost certain the USB device in question here is my yubikeys. What doesn't make sense is that there are yubikey devices in the list, but they all have DEVNAMEs. I think it must be some sub-device of the yubikey that isn't even showing up in this list. Perhaps it isn't always present, only shows up on insert, then is removed? That's my best guess.
Wait...yes, it's obviously yubikey. Some of the sub-devices don't have DEVNAME entries at all. Check out the entry for DEVPATH=/devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.0/0003:1050:0010.0022/input/input59; it doesn't have an attribute called DEVNAME. It doesn't have DEVNAME=<null>, it just doesn't have that attribute, at all.
Ok... maybe we need to go a bit deeper into this. Presuming that the yubikey has device name(s) like /dev/whatever*, could you run the command "udevadm info --atribute-walk /dev/whatever" for each device and attach the output?
Wait... The yubikey presents itself as a hiddev device. We cannot exclude those, lirc has a hiddev driver. So, the brute force method would be to just change the RUN line to RUN+="/usr/bin/sh -c '/usr/bin/setfacl -m g:lirc:rw %E{DEVNAME} 2>/dev/null || :'" There is "udevadm control --reload". However, udev uses inotity to pick up changes in the rules files, so it shouldn't really be needed. So, your testing should be fine. This should work, but... Time to test?
(In reply to Alec Leamas from comment #23) > Wait... The yubikey presents itself as a hiddev device. We cannot exclude > those, lirc has a hiddev driver. So, the brute force method would be to just > change the RUN line to > > RUN+="/usr/bin/sh -c '/usr/bin/setfacl -m g:lirc:rw %E{DEVNAME} > 2>/dev/null || :'" > > There is "udevadm control --reload". However, udev uses inotity to pick up > changes in the rules files, so it shouldn't really be needed. So, your > testing should be fine. > > This should work, but... Time to test? At least make it RUN+="/usr/bin/sh -c '[ -e $env{DEVNAME} ] && /usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}'" although the test in the udev rule should be enough. I would go with KERNEL=="?*": ACTION=="add", SUBSYSTEM=="usb", KERNEL=="?*", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}"
No, wait again... I have done some testing, and actually the condition ENV{DEVNAME}!="" should be fine. It just doesn't match if DEVNAME does not exist, obviously expanding ENV{FOO} to "" if FOO does not exist. Which is what we want.Then, the question becomes if there is something wrong with the testing. @paul: given that the youbikey is available as /dev/whatever, could you just do "udevam info /dev/whatever". That would list some lines, the first of which something like P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/... Here we have the device path. lets call it 'path'. Now, do udevadm test -a ADD $path This prints a lot of stuff. Among the last lines you should see run: "commands to run" That should demonstrate if the rule triggers or not @Harald: Thanks for input! I think that rule will fail when $env{DEVNAME} expands to nothing. The test command will be missing an argument and will return some error code. A one-line if-statement should fix it, but if the code becomes that complex it might be better to install a script, I guess. Basic problem is that we cannot quote.
ENV{DEVNAME}=="?*" should cover your case
So, Paul, can you test that i. e., the following rule: ACTION=="add", SUBSYSTEM=="usb", ENV{DEVNAME}=="?*", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}"
Okay, first, I have the new test command in place. We'll see... Secondly, I ran a new udevadm info command to look at the device list. The device has several /dev/... files: /dev/hidraw? and /dev/input/event? and /dev/bus/usb/..., for example. But, all of these are associated with udevadm entries that have DEVNAME defined. Several other udevadm entries do not have DEVNAME defined. When I use 'udevadm test -a ADD $path' on them I get the outputs I will attach, next. It looks to me like the new rule worked as the 'test' didn't say anything about running setfacl.
Created attachment 1192028 [details] udevadm test -a ADD <path> output Actually, I'll just upload one. Let me know if you want to see the others, I forgot I would have to do them separately. It think it worked, though, so I'm not sure it's necessary to send more.
> Okay, first, I have the new test command in place. We'll see... I. e., the rule from comment #27, right? Well, the basic conclusion is that that the current rule does not match, since the setfacl command doesn't end up in RUN for this device without a DEVNAME. It basically looks sound in test mode. Which leads to the question what happens when a real yubikey is removed/inserted. I presume you cannot do this all by yourself?
(In reply to Alec Leamas from comment #30) > > Okay, first, I have the new test command in place. We'll see... > > I. e., the rule from comment #27, right? Correct. > Well, the basic conclusion is that that the current rule does not match, > since the setfacl command doesn't end up in RUN for this device without a > DEVNAME. It basically looks sound in test mode. > > Which leads to the question what happens when a real yubikey is > removed/inserted. I presume you cannot do this all by yourself? Well, I think this is the answer: Aug 19 20:52:22 <hostname> systemd-udevd[25540]: Process '/usr/bin/setfacl -m g:lirc:rw ' failed with exit code 2. This time stamp matches when when I used a Yubikey. So, I guess the updated rule in comment 27 doesn't work. Here it is, maybe I made an error: ACTION=="add", SUBSYSTEM=="usb", ENV{DEVNAME}=="?*", \ RUN+="/usr/bin/setfacl -m g:lirc:rw $env{DEVNAME}" Yes, I can do this. They are my yubikeys; I just insert them and these errors are produced. Well, I could be more specific. These times match insertion events, but also Yubikey button events. I'm not sure if this happens on insert or only when I press the button. I'm pretty sure it's just the insert event, but I could double check. Let's say it happens on insert. What next?
Next should be Harald's and mu combined wisdom: ACTION=="add", SUBSYSTEM=="usb", ENV{DEVNAME}=="?*", \ RUN+="/usr/bin/sh -c '/usr/bin/setfacl -m g:lirc:rw %E{DEVNAME} 2>/dev/null || :'" That rule just should be silent (knock, knock..
I agree. I'm sure sending STDERR to bit bucket will successfully hide this error from the logs. I'm not interested in trying that, however, since I am just going to remove lirc, anyway. I prefer Hoyer's command that checks for the existence of the DEVNAME file, too. But, again, I am confident this will work and actually stops the error from occurring in the first place. Since adding lirc permission to all USB devices the purpose of this entry, the only thing I can think of that would be useful now is to test a new rule that succeeds on devices that do not have DEVNAME values.
Thanks for all your efforts. I will submit a change along these lines. My impression is that setfacl fails despite that the device exists. This is certainly possible anyway. E. g., I'm not sure all file systems supports acl. But this is basically a "best effort" attempt, so if it fails, it fails. If lirc doesn't have access to the device affecgted, it must be handled separately.
Thank you for all your help and suggestions. I'm happy to be able to turn these strange things that happen on my box into useful data for Fedora maintainers. Thanks for making use of my bug report.
lirc-0.9.4b-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d55c816fac
lirc-0.9.4b-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a745107399
lirc-0.9.4b-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d55c816fac
lirc-0.9.4b-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a745107399
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.