Bug 732360

Summary: picocom should use different locking because of /var/lock permissions
Product: [Fedora] Fedora Reporter: Jiri Kastner <jkastner>
Component: picocomAssignee: Kevin Fenzi <kevin>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 15CC: jpopelka, kevin, ovasik, scottt.tw
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: picocom-1.6-4.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-07 07:48:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
lock.conf for /run/lock none

Description Jiri Kastner 2011-08-22 07:02:01 UTC
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:

Comment 1 Jiri Kastner 2011-08-22 07:38:46 UTC
Created attachment 519236 [details]
lock.conf for /run/lock

Comment 2 Ondrej Vasik 2011-08-22 13:15:10 UTC
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?

Comment 3 Jiri Popelka 2011-08-22 13:57:53 UTC
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.

Comment 4 Ondrej Vasik 2011-08-22 14:02:56 UTC
So ... closing NOTABUG or changing Summary and reassigning to picocom to save virtual trees and bugzilla numbers?

Comment 5 Ondrej Vasik 2011-08-23 14:04:16 UTC
Ok, reassigning to picocom...

Comment 6 Kevin Fenzi 2011-10-26 20:29:12 UTC
Asked upstream about this: 

http://code.google.com/p/picocom/issues/detail?id=15&thanks=15&ts=1319660918

Other easy fixes welcome.

Comment 7 Scott Tsai 2012-01-29 14:36:02 UTC
(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

Comment 8 Kevin Fenzi 2012-01-29 16:41:14 UTC
This looks great Scott. :) Thanks for the fixes. 

I'll push the fix out to updates testing in a few.

Comment 9 Fedora Update System 2012-01-29 17:02:50 UTC
picocom-1.6-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/picocom-1.6-4.fc16

Comment 10 Fedora Update System 2012-01-29 17:12:45 UTC
picocom-1.6-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/picocom-1.6-4.fc15

Comment 11 Fedora Update System 2012-01-30 20:53:40 UTC
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).

Comment 12 Fedora Update System 2012-02-07 07:48:18 UTC
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.

Comment 13 Fedora Update System 2012-02-07 07:56:08 UTC
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.