[Pkg-mpd-maintainers] Bug#849726: mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Konstantin Khomoutov]

On Sat, 31 Dec 2016 09:10:28 +0100
Max Kellermann <max at 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/