[asterisk-dev] Strange issue with permissions and a third party module

[Corey Farrell]

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.
>