Open frispete opened 5 years ago
Does chan_dongle something special permission-wise, that I may have missed?
I don't think so. (A quick grep for uid/perms-functions shows nothing, and I didn't expect any either.)
I even think you listed all the usual suspects.
Isn't the problem that openat() is called twice?
walter@walter-desktop:0:~/Junk$ python3 lckopen.py
walter@walter-desktop:0:~/Junk$ python3 lckopen.py
failed: [Errno 13] Permission denied: '/var/lock/LCK..ttyUSB1'
Please double check the strace?
Thanks, @wdoekes for your quick response.
Isn't the problem that openat() is called twice?
No, here's the filtered strace:
12903 14:32:19.779226 unlink("/var/lock/LCK..ttyUSB1") = -1 ENOENT (No such file or directory)
12903 14:32:19.787335 unlink("/var/lock/LCK..ttyUSB2") = -1 ENOENT (No such file or directory)
12875 14:32:19.789603 openat(AT_FDCWD, "/var/lock/LCK..ttyUSB2", O_RDONLY <unfinished ...>
12875 14:32:19.789685 <... openat resumed> ) = -1 ENOENT (No such file or directory)
12875 14:32:19.789773 unlink("/var/lock/LCK..ttyUSB2" <unfinished ...>
12875 14:32:19.789850 <... unlink resumed> ) = -1 ENOENT (No such file or directory)
12875 14:32:19.790321 openat(AT_FDCWD, "/var/lock/LCK..ttyUSB2", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0444 <unfinished ...>
12875 14:32:19.790429 <... openat resumed> ) = -1 EACCES (Permission denied)
12875 14:32:19.790699 openat(AT_FDCWD, "/dev/ttyUSB2", O_RDWR|O_NOCTTY <unfinished ...>
12875 14:32:19.791132 <... openat resumed> ) = 19
12875 14:32:19.792464 openat(AT_FDCWD, "/var/lock/LCK..ttyUSB1", O_RDONLY <unfinished ...>
12875 14:32:19.792553 <... openat resumed> ) = -1 ENOENT (No such file or directory)
12875 14:32:19.792631 unlink("/var/lock/LCK..ttyUSB1" <unfinished ...>
12875 14:32:19.792774 <... unlink resumed> ) = -1 ENOENT (No such file or directory)
12875 14:32:19.793262 openat(AT_FDCWD, "/var/lock/LCK..ttyUSB1", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0444 <unfinished ...>
12875 14:32:19.793342 <... openat resumed> ) = -1 EACCES (Permission denied)
12875 14:32:19.793606 openat(AT_FDCWD, "/dev/ttyUSB1", O_RDWR|O_NOCTTY <unfinished ...>
12875 14:32:19.793964 <... openat resumed> ) = 20
chan_dongle always tries to unlink the lock file twice before attempting to create the lock, and that call fails. Interestingly, the devices can be accessed properly:
$ 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
It's really puzzling...
Did you strace with -f
? I don't see any pids/tids.
They're in the first column.
Walter, I got an advise from openSUSEs security officer to use the lockdev library instead. What do you think about this? I haven't looked into the details, yet. (Anything auto* scares me away usually...)
Anyway, would you consider such a PR?
They're in the first column.
Sorry, I, missed those. Your strace has different output than mine.
I cannot immediately correlate those unlinks+openats to the calling code, but then again, I didn't look too close.
Have you tried calling lckopen.py from a dialplan System()/SHELL() call?
Anyway, would you consider such a PR?
There's even a ticket for that! https://github.com/wdoekes/asterisk-chan-dongle/issues/6
As long as things still compile without liblockdev, I'll gladly merge.
Have you tried calling lckopen.py from a dialplan System()/SHELL() call?
And tried starting asterisk from a shell instead of from systemd (assuming that's what you're using on opensuse)?
btw, uucp lock directory is slightly different on FreeBSD, so it will be good (and enough):
--- a/chan_dongle.c
+++ b/chan_dongle.c
@@ -116,7 +116,11 @@ static int lock_build(const char * devname, char * buf, unsigned length)
basename = devname;
/* NOTE: use system system wide lock directory */
+ #if defined(__FreeBSD__)
+ return snprintf(buf, length, "/var/spool/lock/LCK..%s", basename);
+ #else
return snprintf(buf, length, "/var/lock/LCK..%s", basename);
+ #endif
}
Hi,
being a happy chan_dongle camper since a few weeks, I'm facing a strange issue with locking. Here's a typical chan_dongle setup log from asterisk:
In current linux distributions (using openSUSE 15.0 here), accessing /var/lock requires to be a member of the lock group:
and /var/lock looks sane as well:
When chan_dongle runs this code, strace reveals, what happens:
Now the fun thing, simulating this call with sudo and a python script succeeds nevertheless:
$ cat /tmp/lckopen.py
strace excerpt:
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.
I've checked any policy related system tools, but they seem innocent as well. My system uses apparmor, I've checked that throughout, but it doesn't know anything about asterisk, hence it will not enforce any kind of special protection. SELinux isn't in use.
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. Does chan_dongle something special permission-wise, that I may have missed?
All my Asterisk related package builds are available in public here.
In short, I'm using 16.0.1 still, and current chan_dongle from this project.
Obviously, this is system related, it would have raised more attention here.
Anyway, any insights are much appreciated.