Mailinglist Archive: opensuse-factory (188 mails)

< Previous Next >
[opensuse-factory] puzzling issue with modem device locking
  • From: Hans-Peter Jansen <hpj@xxxxxxxxx>
  • Date: Wed, 12 Dec 2018 15:07:25 +0100
  • Message-id: <2164698.VGkJDGByXh@xrated>
Hi,

in preparation of submitting the asterisk-chan-dongle package to
telephony:asterisk, I'm facing a strange issue, that must be related
to some policy enforcements, but I don't get the loose ends fixed at
the moment.

Inquiries on asterisk-dev and filing an asterisk-chan-dongle GH issue
doesn't reveal any insights other than it must be an openSUSE specific
issue.

I've raised this issue already on asterisk-dev, but Joshua, a core
developer attested, that Asterisk doesn't do anything special, that
could result in this. Also chan_dongle doesn't something special
permission-wise.

https://github.com/wdoekes/asterisk-chan-dongle/issues/63

The system in question is openSUSE 15.0, but I seriously need to reach
out for some concentrated openSUSE developer neurons here.

Package:

https://build.opensuse.org/package/show/home:frispete:telephony:asterisk/asterisk-chan-dongle

When (re)loading this module in asterisk, it throws errors:

2018-12-11 18:40:11] VERBOSE[2713] chan_dongle.c: [dongle0] Trying to connect
on /dev/ttyUSB2...
[2018-12-11 18:40:11] ERROR[2713] chan_dongle.c: open('/var/lock/LCK..ttyUSB2')
failed: Permission denied
[2018-12-11 18:40:11] ERROR[2713] chan_dongle.c: open('/var/lock/LCK..ttyUSB1')
failed: Permission denied
[2018-12-11 18:40:11] VERBOSE[2713] chan_dongle.c: [dongle0] Dongle has
connected, initializing...
[2018-12-11 18:40:11] VERBOSE[24623] at_response.c: [dongle0] Dongle
initialized and ready

Of course, accessing /var/lock (effectively /run/lock) requires the
process to be a member of the lock group, that the package enforces that:

$ id asterisk
uid=489(asterisk) gid=487(asterisk) groups=54(lock),487(asterisk)

/run/lock looks sane:

$ ls -la /run/lock
total 0
drwxrwxr-x 3 root lock 60 Dec 12 14:32 .
drwxr-xr-x 24 root root 720 Dec 12 13:40 ..
drwxr-xr-x 2 root root 40 Dec 7 17:36 subsys

When chan_dongle tries to lock the device, this code comes into action:

https://github.com/wdoekes/asterisk-chan-dongle/blob/master/chan_dongle.c#L123

but results in (strace excerpt):

openat(AT_FDCWD, "/var/lock/LCK..ttyUSB1", O_WRONLY|O_CREAT|O_TRUNC, 0444) = -1
EACCES (Permission denied)

Now the fun part. Simulating this call with sudo and a python script
succeeds nevertheless:

$ sudo -u asterisk python3 /tmp/lckopen.py
$ ls -la /var/lock/
total 0
drwxrwxr-x 3 root lock 80 Dec 12 12:50 .
drwxr-xr-x 24 root root 720 Dec 9 14:45 ..
-r--r--r-- 1 asterisk asterisk 0 Dec 12 12:50 LCK..ttyUSB1
drwxr-xr-x 2 root root 40 Dec 7 17:36 subsys

$ cat /tmp/lckopen.py
import os
try:
os.open('/var/lock/LCK..ttyUSB1', os.O_WRONLY|os.O_CREAT|os.O_TRUNC, 0o444)
except IOError as e:
print('failed: %s' % e)

strace excerpt:

openat(AT_FDCWD, "/var/lock/LCK..ttyUSB1", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC,
0444) = 3

I patched chan_dongle to add the O_CLOEXEC flag, which python3 seems
to add behind the scenes, but no bonus. Added code to check for uid
and euid on both parties reveals the expected results: the systems
asterisk uid is effectively in use, so there's no reason to fail.

Please note, that the module works properly. It accesses its devices
just fine:

$ ls -la /dev/ttyUSB*
crw-rw---- 1 root asterisk 188, 0 Dec 11 18:38 /dev/ttyUSB0
crw-rw---- 1 root asterisk 188, 1 Dec 12 11:57 /dev/ttyUSB1
crw-rw---- 1 root asterisk 188, 2 Dec 12 14:37 /dev/ttyUSB2

I've checked any policy related system tools, but they seem innocent
as well. We're using apparmor, but we haven't any apparmor profile
for asterisk. It might be enforced by polkit via ModemManager policies,
but given the fact, the devices operate properly, this sounds strange
as well.

Does this issue rings a bell for anybody in the audience?

Any insights are much appreciated.

Thanks in advance,
Pete
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups