If using Fedora / similar systems it could be an SELinux policy issue.
In Fedora /usr/sbin/asterisk is a confined process where python is not.
On Fedora/CentOS SELinux will forbid Asterisk from taking certain
actions even if allowed by the file system permissions set by chmod.
It's possible chan_dongle is doing something that Asterisk / standard
modules does not do so SELinux would block by default, in which case you
could use audit2allow to create a custom SELinux module that would grant
the additional permissions to the asterisk process.
On 12/10/18 12:53 PM, Joshua C. Colp wrote:
On Wed, Dec 5, 2018, at 12:40 PM, Hans-Peter Jansen wrote:
Hi *sters,
looking at a strange issue here. Experimenting with:
https://github.com/wdoekes/asterisk-chan-dongle
is all doing fine so far, but locking the device. While not essential, I would
like to understand, what's going on (wrong). Since chan-dongle handles serial
connections, it attempts to lock them in order to conform to usual Linux
standards. Simply put, it needs to create lock files like this:
/var/lock/LCK..ttyUSB1
In current Linux distributions, that requires it to be a member of the lock
group:
$ getent group lock
lock:x:54:uucp,asterisk
Now this code comes to 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)
Simulating this call with sudo and a python script succeeds nevertheless:
$ sudo -u asterisk python3 /tmp/lckopen.py
$ l /var/lock/
total 0
drwxrwxr-x 3 root lock 100 Dec 5 17:13 ./
drwxr-xr-x 24 root root 720 Dec 3 20:18 ../
-r--r--r-- 1 asterisk asterisk 0 Dec 5 17:13 LCK..ttyUSB1
$ 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.
Why does the Asterisk module behaves differently permission-wise?
How is Asterisk actually run and executed? Is it being run as a systemd unit,
could that be altering permissions and limiting things?
Does Asterisk use some special protection/capabilities for its modules?
Nope, we do nothing special and rely on the system itself. We can drop down to
a different user and such, that's about it.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
