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/ast... 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#L1... 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org