Bug 145459 - "line in use" - misleading error message in "cu"; misleading "cu" man page; troublesome udev permissions
"line in use" - misleading error message in "cu"; misleading "cu" man page; t...
Product: Fedora
Classification: Fedora
Component: uucp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Bill Huang
Depends On:
  Show dependency treegraph
Reported: 2005-01-18 13:03 EST by james
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-08 05:30:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description james 2005-01-18 13:03:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 
7.54  [en]

Description of problem:
 $ sudo cu -l/dev/ttyS0 dir
 /usr/bin/cu: /dev/ttyS0: Line in use

The error message is both wrong and misleading.  The line is NOT "in 
use" - so "wrong".   The actual problem is with the "device" and "cu" 
file permissions not matching - so "misleading".

Even more confusing, "cu" requires that the running "cu" have BOTH 
user and group permissions on the device.  Furthermore, RedHat, by 
default, has mode "suid uucp" AND "sgid uucp" for "cu".  Both of 
these characteristics, requiring both user and group access 
permissions and running suid/sgid, are NOT typical for many commands.

The "cu" man page fails to mention these permission interactions with 
both the device permissions and the "cu" permissions, suggesting to a 
reasonable person that the permission issues are "ordinary" and as 
"typical for many commands" - which is NOT the case - so 

This "line in use" failure matters because "cu" is the simplest tool 
for testing a serial line connection and is often used by sys admins.

1) "cu" should explicitly state the write permission failures and NOT 
"presume" anything about the line state.  Something like
 /usr/bin/cu: /dev/ttyS0: user: Permission denied
 /usr/bin/cu: /dev/ttyS0: group: Permission denied
to correspond to the existing "read" access failure
 /usr/bin/cu: open (/dev/ttyS0): Permission denied

2) Add a paragraph to the "cu" man page describing the device 
permission requirements of "cu" and "cu"'s possible suid and sgid 
mode settings.

3) in the package "udev", in the "permissions" configuration file,
change the default "ttyS*" user and group to match those of the "cu" 
command - uucp uucp (or visa versa).

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

How reproducible:

Steps to Reproduce:
1.$ sudo cu -l/dev/ttyS0 dir

Actual Results:  /usr/bin/cu: /dev/ttyS0: Line in use

Expected Results:  Connected.

Additional info:

Work-around - change the uid, and gid of "cu" to match those of the 
device file, or visa versa.

In particular, for Fedora udev-039-10.FC3.6, in
there is
 # serial+dialup devices
and this can be changed to

The device permissions could also be changed to be world readable and 
world writable, but this level of access is unnecessarily permissive.
Comment 1 Peter Vrabec 2005-01-19 11:44:23 EST
I can't reproduce your problem.

[peter@wrabco ~]$ ll /dev/ttyS0
crw-rw----  1 root uucp 4, 64 Jan 19 15:57 /dev/ttyS0
[peter@wrabco ~]$ ll /usr/bin/cu
-r-sr-sr-x  1 uucp uucp 496726 Nov 19 13:02 /usr/bin/cu
[peter@wrabco ~]$ sudo cu -l/dev/ttyS0 dir
Comment 2 james 2005-01-19 23:08:54 EST
Hmm.  Partly my fault - I had been playing around with the 
permissions on cu.

# ll /dev/ttyS1
crw-rw----  1 root uucp 4, 65 Sep 21 16:56 /dev/ttyS1
# ll /usr/bin/cu
-r-sr-sr-x  1 uucp uucp 502455 Oct 14 07:38 /usr/bin/cu
# cu -l/dev/ttyS1 dir
# chmod 0555 /usr/bin/cu
# ll /usr/bin/cu
-r-xr-xr-x  1 uucp uucp 502455 Oct 14 07:38 /usr/bin/cu
# cu -l/dev/ttyS1 dir
cu: /dev/ttyS1: Line in use

Now, the man page says:

 If the argument is the string "dir"  cu  will  make  a direct 
connection to the port.  This may only be used by users with write 
access to the port, as it permits reprogramming the modem.

but "user" write access is not good enough here.  It looks like 
"group" write access - specifically - or "world" write access is 

# chown nobody.root /dev/ttyS1
# ll /dev/ttyS1
crw-rw----  1 nobody root 4, 65 Jan 19 19:51 /dev/ttyS1
# cu -l/dev/ttyS1 dir

But then I see this:

chmod 6555 /usr/bin/cu
# ll /usr/bin/cu
-r-sr-sr-x  1 uucp uucp 502455 Oct 14 07:38 /usr/bin/cu
# cu -l/dev/ttyS1 dir

So cu is running suid and sgid uucp and the device is owned by user 
nobody and group root, no world access.  Yet now, cu can access the 
device, seemingly without any kind of write access.
ps -o "%U %G %a" -u uucp
uucp     uucp     cu -l/dev/ttyS1 dir
uucp     uucp     cu -l/dev/ttyS1 dir

Is this something to do with the real gid running - root?
# chown nobody.nobody /dev/ttyS1
# ll /dev/ttyS1
crw-rw----  1 nobody nobody 4, 65 Jan 19 20:23 /dev/ttyS1
# cu -l/dev/ttyS1 dir
$ ps -o "%U %G %a" -u uucp
uucp     uucp     cu -l/dev/ttyS1 dir
uucp     uucp     cu -l/dev/ttyS1 dir

This does not look right.  Sometimes cu doesn't work when it looks 
like it should, and does work when it looks like it should not.
Comment 3 Peter Vrabec 2005-02-08 05:30:39 EST
cu has to be suid and any user, who want to use it, should be member
of uucp group.

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