Hide Forgot
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): filesystem-2.4.41-1.fc15.x86_64 How reproducible: always 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 Actual results: FATAL: cannot lock /dev/ttyS0: Permission denied Expected results: Terminal ready Additional info:
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: http://code.google.com/p/picocom/issues/detail?id=15&thanks=15&ts=1319660918 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: https://www.gitorious.org/fedora-packages/picocom/commit/c20c2a4951baed91a0ea6252bbffe567e04fe2c0 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: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/rules.d/50-udev-default.rules;h=240cb3b3a6a940b087274e31f655ff3b4f3a3753;hb=662c3110803bd8c1aedacc36788e6fd028944314 In Fedora, GID 18 is reserved for "dialout" in the setup package: http://git.fedorahosted.org/git/?p=setup.git;a=commitdiff;h=1e61a60c8fbedd05672b121ff51dc298c653dc78;hp=0ab82e8ac593ab535bfdd00eedd0a198994f26bd
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. https://admin.fedoraproject.org/updates/picocom-1.6-4.fc16
picocom-1.6-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/picocom-1.6-4.fc15
Package picocom-1.6-4.fc16: * 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: https://admin.fedoraproject.org/updates/FEDORA-2012-1027/picocom-1.6-4.fc16 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.