mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Michael Biebl]

Am 30.12.2016 um 08:26 schrieb Konstantin Khomoutov:
> Package: mpd
> Version: 0.19.21-1
> Severity: important
> 
> Hi!
> 
> After upgrading an i686 machine running mpd from Jessie to Stretch,
> I noticed mpd won't start -- exiting with return code 1 early at
> startup:
> 
> | Dec 30 10:16:52 jukebox systemd[1]: [/lib/systemd/system/mpd.service:25] Unknown lvalue '

' in section 'Service'
> | Dec 30 10:16:54 jukebox systemd[1]: Started Music Player Daemon.
> | Dec 30 10:16:55 jukebox mpd[4936]: config_file: loading file /etc/mpd.conf
> | Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Main process exited, code=exited, status=1/FAILURE
> | Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Unit entered failed state.
> | Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Failed with result 'exit-code'.
> 
> Running
> 
>   /usr/bin/mpd --no-daemon -v /etc/mpd.conf
> 
> by hand as root worked OK, so I've changed the ExecStart parameted in
> the Systemd unit to
> 
>   /usr/bin/strace -o /tmp/mpd.log -f /usr/bin/mpd --no-daemon -v $MPDCONF
> 
> commented out all the system protection options, then started to
> uncomment them one by one -- attempting to start the unit each time
> (with proper invocations of `systemctl daemon-reload` in between).
> 
> Finally this spotted the problem which is the
> 
>   RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
> 
> option.  With it being commented out, mpd starts OK.
> 
> Analyzing the strace output for relevant problems brought up several
> attempts at opening sockets -- of types AF_UNIX and AF_INET.
> Several of such failed attempts apparently get ignored by mpd, but the
> last one actually makes it exit (silently for whatever reason) but with
> the result code of 1.
> The last lines of the strace's output are:
> 
> | 4938  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
> | 4938  exit_group(1)                     = ?
> | 4938  +++ exited with 1 +++
> 
> and the result of grepping it for EPROTONOSUPPORT is:
> 
> | 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
> | 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
> | 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
> | 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
> | 4743  socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = -1 EPROTONOSUPPORT (Protocol not supported)
> | 4743  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
> 
> 
> As to the essense of this but, it rather appears to affect Systemd v232
> (as shipped by Stretch) specifically on i686 systems [1].
> 
> That bug's thread mentions [2], so I've added the unstable repository
> and attempted to install systemd from there via
> 
>   apt install -t unstable systemd
> 
> but it told me the package I have installed is already the newest
> version, and its changelog has the following snippet:
> 
> ----------------8<----------------
> systemd (232-2) unstable; urgency=medium
> 
>   * Drop RestrictAddressFamilies from service files.
>     RestrictAddressFamilies= is broken on 32bit architectures and causes
>     various services to fail with a timeout, including
>     systemd-udevd.service.
>     While this might actually be a libseccomp issue, remove this option for
>     now until a proper solution is found. (Closes: #843160)
> 
>  -- Michael Biebl <biebl at debian.org>  Sat, 05 Nov 2016 22:43:27 +0100
> ----------------8<----------------
> 
> So it appears you'd better comment that option as well for now of ship
> a dedicated unit files specifically for i686 systems if this is
> possible.
> 
> OTOH, upstream appears to have some developments on [1], so maybe asking
> systemd maintainers on whether it's possible to integrate some upstream
> fix for this seccomp issue is worthwhile.

Your analysis seems to be correct. Until systemd is fixed, you should
not use RestrictAddressFamilies=

I'm not sure whether we will get v233 for stretch and if backporting
those upstream fixes for v232 is feasible.

As for RestrictNamespaces=, I'm pretty sure we won't backport that
feature for v232, so I'd suggest removing that as well for now until
v233 is actually available.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20161231/c8bb96f5/attachment-0001.sig>