As Debian bug #264626 says eloquently, it is damned annoying when even root can't use a command due to permission errors.

Basically legacy script from Redhat 7.2 (!) failed to run under Debian, no "cu" command. Easy to fix I think.

# apt-get install cu 
# cu -l /dev/ttyS0
cu: open (/dev/ttyS0): Permission denied

Running "cu" under strace, shows that it changes the effective permissions;

open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = -1 EACCES (Permission denied)
geteuid32()                             = 10
getuid32()                              = 10
getegid32()                             = 0
getgid32()                              = 0

So cu becomes "uucp:root", but /dev/ttyS0 is owned "root:dialout" with 660. I think this is a straight bug, and that "cu" shouldn't change permissions on Debian, as users with dialout permissions are in group dialout, and root should be able to do anything (in the current security model anyway).

Since the executable isn't setuid in the file system, presumably this only affects root, I can't see how it might be used in a technical attack, but the patch is to remove the setregid32, and setregid32 calls from the code. Of course a social engineering attack might begin "it is suid and setgid uucp on our Redhat box, can you fix 'cu' permissions on Debian?"....

I'll fix our scripts to run as a non-root user, and put that user in the "dialout" group.

I'd write a patch if I could be sure it would ever make it into Debian. I also want to know why "cu" tries to close all the file descriptors on start-up, I assume this is some sort of hardening for those platforms daft enough to ship it with setuid bits set, as I've seen explanations of how stray file handles can be an issue with setuid code. I suspect, based on strace output, on boxes where this script is setuid it may have more security horrors to reveal to sharper minds than mine.