Description of problem: I'm using an irman receiver that is connected as a serial device on ttySO and the new default configuration in F22 when lircd runs as user lirc fails because it tries to lock the serial port after it has changed user: Aug 15 11:25:49 hampton.compton.nu systemd[1]: Started LIRC Infrared Signal Decoder. Aug 15 11:25:49 hampton.compton.nu systemd[1]: Starting LIRC Infrared Signal Decoder... Aug 15 11:25:49 hampton.compton.nu lircd-0.9.2a[2025]: Notice: Running as user lirc Aug 15 11:25:49 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Notice: Running as user lirc Aug 15 11:25:49 hampton.compton.nu lircd-0.9.2a[2025]: Info: Using remote: harmony.conf. Aug 15 11:25:49 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Info: Using remote: harmony.conf. Aug 15 11:25:49 hampton.compton.nu lircd-0.9.2a[2025]: Info: Using remote: hitachi.conf. Aug 15 11:25:49 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Info: Using remote: hitachi.conf. Aug 15 11:25:49 hampton.compton.nu lircd-0.9.2a[2025]: Notice: lircd(irman) ready, using /var/run/lirc/lircd Aug 15 11:25:49 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Notice: lircd(irman) ready, using /var/run/lirc/lircd Aug 15 11:26:33 hampton.compton.nu lircd-0.9.2a[2025]: Notice: accepted new client on /var/run/lirc/lircd Aug 15 11:26:33 hampton.compton.nu lircd-0.9.2a[2025]: could not create lock file "/var/lock/lockdev/LCK..ttyS0": Permission denied Aug 15 11:26:33 hampton.compton.nu lircd-0.9.2a[2025]: Error: could not create lock files Aug 15 11:26:33 hampton.compton.nu lircd-0.9.2a[2025]: Warning: Failed to initialize hardware Aug 15 11:26:33 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Notice: accepted new client on /var/run/lirc/lircd Aug 15 11:26:33 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: could not create lock file "/var/lock/lockdev/LCK..ttyS0": Permission denied Aug 15 11:26:33 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Error: could not create lock files Aug 15 11:26:33 hampton.compton.nu lircd[2025]: lircd-0.9.2a[2025]: Warning: Failed to initialize hardware It seems that it doesn't try and open and lock the device until the first client connects, by which time the user transition has occurred? Version-Release number of selected component (if applicable): lirc-0.9.2a-1.fc22.x86_64
The quick "fix" would be to remove the 'effective-user' option from lirc_options.conf. Running lircd as root is bad, bot no worse than it was in F21. That said, thanks for reporting this. There are probably other quirks when running as non-root. Need to grab a new, upstream hat and look into this. More substantial fixes will probably not make it for 0.9.3, though. The serial stuff is also special, the locking permissions adds some complexity besides the pure devices which can be handled by udev rules. Leaving bug open for now, so it's visible to others.
Yes I already switched back to running as root - my first attempted fix was to add lock as a secondary group for lirc but it doesn't actually switch the primary group, or reset secondary groups, when it changes the euid. I suspect it would then have failed opening the actual device anyway.
(In reply to Tom Hughes from comment #2) > Yes I already switched back to running as root - my first attempted fix was > to add lock as a secondary group for lirc but it doesn't actually switch the > primary group, or reset secondary groups. Yes, this is at least part of the problem. Current setuid code does not set the supplementart groups as it should. This seems like a simple fix which should make it to 0.9.3
Upstream patch at [1]. This should at least ensure that the supplementary groups are OK also after a --effective-user privilege drop. Stay tuned, 0.9.3 is under way... [1] https://sourceforge.net/p/lirc/git/ci/ec7e926987a61271ff5c87567e10df98ec72216b/
Should it not change the primary group as well? Currently when --effective-uid is use it continues running in group root and I don't think that patch will change that.
Oops, thanks for fresh eyes! Will fix!
New try: https://sourceforge.net/p/lirc/git/ci/58374e7b290997925b4bd
lirc-0.9.3-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15207
lirc-0.9.3-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15228
lirc-0.9.3-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update lirc'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15207
lirc-0.9.3-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15270
lirc-0.9.3-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update lirc'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15270
lirc-0.9.3-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update lirc'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15228
lirc-0.9.3-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15465
lirc-0.9.3-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update lirc'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15465
lirc-0.9.3-5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Original report was against fc22, my USB UIRT works when I put: /usr/sbin/lircd --nodaemon --effective-uid=0 --device=/dev/ttyUSB0 --driver=uirt2_raw into /lib/systemd/system/lircd.service file.
hm... - Which version are you on? - what's your lirc version? - What says ls -l /dev/ttyUSB0?
# ls -l /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Dec 20 17:08 /dev/ttyUSB0 # /usr/sbin/lircd --nodaemon --device /dev/ttyUSB0 --driver uirt2_raw lircd-0.9.2a[29221]: Illegal effective uid: 0: Success lircd-0.9.2a[29221]: Info: Using remote: irrecord.conf. [ start irw in another console ] lircd-0.9.2a[29221]: Notice: lircd(uirt2_raw) ready, using /var/run/lirc/lircd lircd-0.9.2a[29221]: Notice: accepted new client on /var/run/lirc/lircd lircd-0.9.2a[29221]: Warning: uirt2_raw: Old UIRT hardware lircd-0.9.2a[29221]: Error: uirt2_raw: checksum error ^Clircd-0.9.2a[29221]: Notice: caught signal lircd-0.9.2a[29221]: Error: uirt2_raw: checksum error # rpm -qa|grep lirc lirc-0.9.2a-3.fc22.x86_64 lirc-tools-gui-0.9.2a-3.fc22.x86_64 lirc-core-0.9.2a-3.fc22.x86_64 lirc-libs-0.9.2a-3.fc22.x86_64 # ls -l /var/run/lirc/ total 4 srw-rw-rw- 1 root root 0 Dec 20 17:07 lircd -rw-r--r-- 1 root root 6 Dec 20 17:07 lircd.pid # getenforce Disabled Running it with uid=0 works fine. I put it into systemd service file, imo you can't put that into lircd.conf. # /usr/sbin/lircd --nodaemon --effective-uid 0 --device /dev/ttyUSB0 --driver=uirt2_raw
Ah, and while trying to get this working, at some point I added lirc dude into lock group (usermod -a -G lock lirc) : # id lirc uid=487(lirc) gid=485(lirc) groups=485(lirc),18(dialout),54(lock),492(input) not sure would it break uid=0 if I would take it away. Something to try anyway.
# ls -l /var/lock/ total 4 -rw-r--r-- 1 root root 22 Dec 20 17:34 asound.state.lock drwx------ 2 root root 60 Dec 18 13:12 iscsi drwxrwxr-x 2 root lock 60 Dec 20 17:08 lockdev drwx------ 2 root root 40 Dec 18 13:12 lvm drwxr-xr-x 2 root root 40 Dec 18 13:12 ppp drwxr-xr-x 2 root root 60 Dec 18 13:12 subsys [root@wasa lircd.conf.d]# ls -l /var/lock/lockdev/ total 4 -rw-r--r-- 1 root root 11 Dec 20 17:08 LCK..ttyUSB0
so, we have the ownerships and permission, and those looks good. If you lookup the pid for the lircd process, what does grep Groups /proc/$pid/status say? Also, can you map those numbers to the group names using /etc/group?