polkit and serial line connections

[ummelum]

i have a plain vanilla default install of xubuntu. i need to access a terminal, which is directly connected...

$ ls /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Nov 30 19:59 /dev/ttyS0

i did...

$ sudo apt-get install cu

which went fine and dropped cu in /usr/bin. i used apt-get because cu isn't available in the software center.

as a user, part of the groups 'dialout', 'adm' and 'sudo', i tried...

$ cu -l /dev/ttyS0 -s 115200

which didn't work. the serial port is the correct one, as well as the baudrate, parity, ...

so i tried...

$ sudo cu -l /dev/ttyS0 -s 115200
/usr/bin/cu: open (/dev/ttyS0): Permission denied
/usr/bin/cu: /dev/ttyS0: Line in use

then i did..

$ sudo su -

which gave me a root prompt, where i tried...

# cu -l /dev/ttyS0 -s 115200
/usr/bin/cu: open (/dev/ttyS1): Permission denied
/usr/bin/cu: /dev/ttyS1: Line in use

is this is a polkit thing? an udev thing? if i boot this box in openbsd or netbsd, cu will connect just fine.

we're in the year 2012, and a modern unix apparently can't connect to a serial line?

[ummelum]

i retried the above scenarios with policykit's pkexec, with the same results...

[ummelum]

to make sure this wasn't a polkit thing, i made an action definition for this, and dropped it in /etc/polkit-1/actions

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN""http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>
<action id="org.freedesktop.policykit.exec">
    <defaults>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/cu</annotate>
    <annotate key="org.freedesktop.policykit.exec.argv1">-l /dev/ttyS0 -s 115200</annotate>
    <annotate key="org.freedesktop.policykit.imply >true</annotate>
    <annotate key="org.freedesktop.policykit.owner>unix-user:ummelum</annotate>
  </action>
</policyconfig>

i ran it...

exec /usr/bin/pkexec --user ummelum /usr/bin/cu -l /dev/ttyS0 -s 115200

but results were similar as in my posts above.

according to /var/log/auth.log, the policy worked...

Dec  1 22:51:54 iugo polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session1 successfully authenticated as unix-user:ummelum to gain ONE-SHOT authorization for action org.freedesktop.policykit.exec for unix-process:5798:3872562 [bash] (owned by unix-user:ummelum)
Dec  1 22:51:54 iugo pkexec: pam_unix(polkit-1:session): session opened for user root by ummelum(uid=1000)
Dec  1 22:51:54 iugo pkexec: pam_ck_connector(polkit-1:session): cannot determine display-device
Dec  1 22:51:54 iugo pkexec[6047]: ummelum: Executing command [USER=root] [TTY=/dev/pts/0] [CWD=/home/ummelum] [COMMAND=/usr/bin/cu -l /dev/ttyS0 -s 115200]

so this isn't a polkit thing. i'd love to have someone shine some light on this...

[ummelum]

i suspect this is restricted by pam's capabilities...

so i added a line to /etc/security/group.conf

cu;*;ummelum;Al0000-2400;dialout

and created /etc/pam.d/cu

session	optional	pam_permit.so

i used a login-shell and tried my serial console, but alas..

if i try with pkexec, from a login-shell, i get the following in /var/log/auth.log:

Dec  1 23:49:02 iugo polkitd(authority=local): Unregistered Authentication Agent for unix-process:914:1133 (system bus name :1.73, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

can anyone tell me if the above pam-policy is correct, or give me a solution to my problem?

[ummelum]

and apparently i'm not the only one with this problem:

http://ubuntuforums.org/showthread.php?p=12345518

[ummelum]

and even more people with the same problem, all during the last weeks...

http://ubuntuforums.org/showthread.php?t=2087953
http://ubuntuforums.org/showthread.php?t=2082610

[ummelum]

can someone clue me in why this isn't working as it should? i find it hard to believe i'm the only ubuntu-user that needs a working serial port.

[ummelum]

silent bump, and link to the launchpad bug:
https://bugs.launchpad.net/ubuntu/+bug/1087519

[ummelum]

let's try as a user with sufficient rights:
$ strace -f -ff -o STRACE_CU cu -l /dev/ttyS0 -s 115200

Connected.

but it doesn't relay the serial console. i can abort this with the usual "~." if i have enough patience and if i break (^C) it a few times.

$ cat STRACE_CU.*|grep EPERM

ioctl(3, TIOCSCTTY)                     = -1 EPERM (Operation not permitted)

why isn't the actual terminal allowed to take control?

$ excerpt from STRACE_CU.*:

open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = 3
geteuid32()                             = 1000
getuid32()                              = 1000
getegid32()                             = 1000
getgid32()                              = 1000
setregid32(1000, 1000)                  = 0
setreuid32(1000, 1000)                  = 0
fcntl64(3, F_GETFD)                     = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
access("/dev/ttyS0", R_OK|W_OK)         = 0
fcntl64(3, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(3, F_SETFL, O_RDWR)             = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCFLSH, 0)                     = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TIOCSCTTY)                     = -1 EPERM (Operation not permitted)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
access("/dev/ttyS0", R_OK|W_OK)         = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ca000
write(1, "\7Connected.\n", 12)          = 12
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
pipe([4, 5])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb760e968) = 2670
close(5)

let's try with elevated rights:
$ sudo strace -f -ff -o SUDO_STRACE_CU cu -l /dev/ttyS0 -s 115200

cu: open (/dev/ttyS0): Permission denied
cu: /dev/ttyS0: Line in use

and it exits cleanly...

$ cat SUDO_STRACE_CU.*|grep "open"|grep "ttyS0"

open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = -1 EACCES (Permission denied)
write(2, "cu: open (/dev/ttyS0): Permissio"..., 41) = 41

$ excerpt from SUDO_STRACE_CU.*

open("/dev/ttyS0", O_RDWR|O_NONBLOCK)   = -1 EACCES (Permission denied)
geteuid32()                             = 10
getuid32()                              = 10
getegid32()                             = 0
getgid32()                              = 0
setregid32(0, 0)                        = 0
setreuid32(10, 10)                      = 0
write(2, "cu: open (/dev/ttyS0): Permissio"..., 41) = 41
unlink("/var/lock/LCK..ttyS0")          = 0
write(2, "cu: /dev/ttyS0: Line in use\n", 28) = 28
exit_group(1)                           = ?

if anyone is interested in the full traces, just ask...

[ummelum]

i just made user 'root' part of the groups tty, dialout and uucp. using sudo, or the root account, gives me the same behavior as using a normal user now...