From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.54 [en] Description of problem: Where $ sudo cu -l/dev/ttyS0 dir gives /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 "misleading". 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. Recommendations: 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): uucp-1.07-3 How reproducible: Always Steps to Reproduce: 1.$ sudo cu -l/dev/ttyS0 dir 2. 3. 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 /etc/udev/permissions.d/50-udev.permissions there is # serial+dialup devices ttyS*:root:uucp:0660 and this can be changed to ttyS*:uucp:uucp:0660 The device permissions could also be changed to be world readable and world writable, but this level of access is unnecessarily permissive.
I can't reproduce your problem. uucp-1.07-5 [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 Password: Connected.
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 Connected. # 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 required. # 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 Connected. 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 Connected. 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 USER GROUP COMMAND 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 Connected. $ ps -o "%U %G %a" -u uucp USER GROUP COMMAND 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.
cu has to be suid and any user, who want to use it, should be member of uucp group.