Description of problem:
/var/lock is link to /var/run/lock, where /var/run is link to /run. i can't lock ttyS0 despite of fact, that user is in lock group, because there is root group instead of lock and group rights are only rx. i assume, that lock group is in /etc/group for this purpose and that will have write access to /run/lock.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. picocom -b 115200 /dev/ttyS0
2. FATAL: cannot lock /dev/ttyS0: Permission denied
3. sudo chgrp lock /run/lock
4. picocom -b 115200 /dev/ttyS0
5. FATAL: cannot lock /dev/ttyS0: Permission denied
6. sudo chmod g+rwx /run/lock
7. picocom -b 115200 /dev/ttyS0
8. Terminal ready
FATAL: cannot lock /dev/ttyS0: Permission denied
Created attachment 519236 [details]
lock.conf for /run/lock
Thanks for report, Jirka. Permissions root:root 755 are intentional - see https://bugzilla.redhat.com/show_bug.cgi?id=693394 and https://bugzilla.redhat.com/show_bug.cgi?id=581884 . Adding lockdev maintainer to CC - Jirka P., what do you think?
Yes root:root 755 is intentional.
This is what Lennart stated in description of bug #692714:
"From all the ways the various distributions have set up /var/lock and subdirectories the Fedora way seems the most reasonable and the folks from the other distros appear to agree ..."
I guess picocom should either create locks in subdirectory of /run/lock, for example in
drwxrwxr-x root lock /var/lock/picocom
or use lockdev for locking of devices.
So ... closing NOTABUG or changing Summary and reassigning to picocom to save virtual trees and bugzilla numbers?
Ok, reassigning to picocom...
Asked upstream about this:
Other easy fixes welcome.
(In reply to comment #6)
Kevin, I came up with a trivial upstream patch and some packaging changes to make picocom store lock files under /run/lock/picocom/ (patch already attached in upstream issue 15)
Could you take a look at these changes:
and pull it if you approve?
The rationale for creating /run/lock/picocom/ with permissions:
drwxrwxr-x. root dialout /run/lock/picocom/
is so that a Fedora user could add herself to the "dialout" group and have access to /dev/tty* and /run/lock/picocom/
"dialout" Group ownership of /dev/tty* is in the udev default rules:
In Fedora, GID 18 is reserved for "dialout" in the setup package:
This looks great Scott. :) Thanks for the fixes.
I'll push the fix out to updates testing in a few.
picocom-1.6-4.fc16 has been submitted as an update for Fedora 16.
picocom-1.6-4.fc15 has been submitted as an update for Fedora 15.
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing picocom-1.6-4.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
picocom-1.6-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
picocom-1.6-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.