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. -- Joshua C. Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- 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
