Bug 732360 - picocom should use different locking because of /var/lock permissions
Summary: picocom should use different locking because of /var/lock permissions
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: picocom
Version: 15
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-22 07:02 UTC by Jiri Kastner
Modified: 2012-02-07 07:56 UTC (History)
4 users (show)

Fixed In Version: picocom-1.6-4.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 07:48:18 UTC


Attachments (Terms of Use)
lock.conf for /run/lock (160 bytes, patch)
2011-08-22 07:38 UTC, Jiri Kastner
no flags Details | Diff

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.


Note You need to log in before you can comment on or make changes to this bug.