Bug 52286

Summary:	User's can't open devices
Product:	[Retired] Red Hat Public Beta	Reporter:	George Thomas <gthomas>
Component:	minicom	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	roswell	CC:	mharris
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-08-22 22:28:20 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:

Description George Thomas 2001-08-22 12:47:01 UTC

Description of Problem:
Permission problems locking device.

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. Create a configuration 'ttyS0' as root using 'minicom -s'
2. Open device as a normal user.

3. 

Actual Results:
   [gthomas@hermes gthomas]$ minicom -o ttyS0
   Device /dev/ttyS0 lock failed.


Expected Results:


Additional Information:

Comment 1 Mike A. Harris 2001-08-22 15:31:40 UTC

Reassigning to jbj who did the recent locking stuff...

Comment 2 Jeff Johnson 2001-08-22 15:48:09 UTC

Are you using
	lockdev-1.0.0-11
	minicom-1.83.1-15
If not, upgrade to those packages, as there was a mismatch
between the two packages that caused this type of failure.

If the above versions don't work, please reopen this bug.

Comment 3 Glen Foster 2001-08-22 22:07:42 UTC

We (Red Hat) really need to fix this before next release.

Comment 4 George Thomas 2001-08-22 22:12:04 UTC

What more detail can I provide?  I installed Roswell(RC1).  I tried to use
an existing minicom configuration which accesses one of my serial ports (I
upgraded from 7.1) and gor the 'Device lock' message above.

I then recreated the configuration (as root: minicom -s).  When I run it
as a non-root user, same error.

Jeff suggested that I install minicom-1.83.1-15 (of course, he couldn't
point me to an RPM for it, so I built is from the SRPM he provided).  I
then installed this and it still fails - exact same scenario.

Comment 5 Jeff Johnson 2001-08-22 22:28:14 UTC

No more information is needed, the management unit is just
doing their management thing :-)

Meanwhile, I had not looked at the -o ttyS0 pathway, only
the default "minicom -s" pathway when using a helper binary
to lock the device.

Comment 6 Jeff Johnson 2001-08-28 19:13:51 UTC

Another zig-zag. lockdev-1.0.0-13 has access(2) checks on the
device, errno's are now explicitly mapped through /usr/sbin/lockdev
helper status returns, and minicom-1.83.1-16 does it's own
access(2) to disambiguate lock failure from device access failure.

Make sure you have both lockdev-1.0.0-13 and minicom-1.83.1-16
packages installed for functionality, this will not be addressed through
dependencies as the fault is entirely contained in beta software. You
will also need lockdev-devel-1.0.0-13 in order to rebuild minicom (and
soon uucp) correctly.

Basically this is what is happening
	1) minicom no longer needs setuid uucp access to /var/lock
	as those permissions are handled by setgid lock /use/sbin/lockdev
	helper.
	2) minicom user still needs access to the device through
	usual system administration.
	3) the device access checks have been moved from the open to
	the lock acquisition phase of minicom.