On Sat, 31 Dec 2016 09:10:28 +0100 Max Kellermann <m...@duempel.org> wrote:
Hi, Max! > > | 4938 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 > > | EPROTONOSUPPORT (Protocol not supported) 4938 exit_group > > | (1) = ? 4938 +++ exited with 1 +++ > > There are two problems with your findings: > > 1. MPD does not contain any code which creates SOCK_DGRAM, even less > so with AF_UNIX. This is not MPD! > It seems like you're (part of) upstream for mpd, so I'm a bit at a loss confronting your rebuttal but still here's my take ;-) It appears that mpd loads pretty a number of libraries at startup; at least on Debian. At least I've spotted libsmbclient [*] and something related to avahi (running mpd with the "-v" command-line option helped me with this). So I'm inclined to think that's supposedly not mpd but rather some of the libraries it pulled in and called out to some of their initialization code. > 2. Any time MPD exits due to a failure, it will print an error > message. This process does not. Again, what you see here is not > MPD! I'm not sure a sane library would call exit(1) or something like this on its initialization failure but I reckon mpd might have some code path initializing some library which it just does not expect to fail ever. Unfortunately, the `strace` tool only intercepts syscalls (or even libc wrappers around them? -- I don't know for sure) so it's unable to tell which code was executing when it recorded an access to that syscall. Properly figuring this out requires actually running mpd under Debian's current systemd with unmodified unit's settings and then somehow attaching gdb to it, setting a breakpoint on socket() and figuring one what code path led to that one which makes mpd quit. Unfortunately, I have too much work on my hands ATM so I can't properly investigate this issue myself (even though I'm into this sort of things, really) but may be you could grab some Vargant image with Debian/i686 and play with it? Or, I think, it's possible to ask for restricted access to one of "porter boxes" of the Debian infrastructure running i686 H/W. Oh, and I personally have one such box accepting SSH from the internets, so just ask ;-) > 3. Why do you get EPROTONOSUPPORT even though AF_UNIX is allowed? Not > a MPD bug, but maybe a systemd bug. As I gather from [1], using RestrictAddressFamilies in a systemd unit file makes systemd use the so-called seccomp subsystem of the Linux kernel which allows filtering of syscalls [2]. Apparently the code systemd uses for this is broken on i386 (i686 at least). As you can see, with seccomp filtering enabled the wrong way, a syscall which looks otherwise fine will mysteriously fail; I reckon that's what we're observing. [*] For me, the journey with this mpd bug started with mpd mysteriously writing | Unknown option encountered "printer admin" | Ignoring unknown parameter "printer admin" to its stdout. As usually, googling gor the exact error message turned out it's a problem with my (very old) SAMBA configuration file for the SAMBA server instance running on that same box hosting mpd. That's how I discovered mpd loads libsmbclient at startup. 1. https://github.com/systemd/systemd/issues/4575 2. https://lwn.net/Articles/656307/