Bug#849817: [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 13:49:34 +0100
Florian Schlichting <fsfs at debian.org> wrote:

> > > 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.
> > 
> > Would it be possible then to temporarily patch systemd as will be
> > shipped in Stretch to just fail loading the unit with a descriptive
> > error message if it contains the RestrictAddressFamilies directive
> > *and* systemd is running on a 32-bit architecture (I think we have
> > i686 and x32 by now)?
> 
> or, even better, not fail outright but ignore RestrictAddressFamilies
> and issue a warning about it?

Let me disagree.

Warnings do have their place, but I'd say it's mostly about deprecating
currently supported stuff in some (distant) future.

Failure to properly provide feature X when it was requested by the user
is an error.  Let me back my claim up: suppose I've installed a program
which is supposed to be properly sandboxed (network-wise in this
particular case).  It starts up and works, and to me, this means it's
all OK, and sandboxing is active -- except that it isn't.  Conversely,
a complete failure to run will force the administrator to investigate
the issue.  And the (prospective) error message will hint them to
consciously disable that feature (comment it out).

On the other hand, a warning could be better precisely because it won't
require the use to comment stuff out: since unit files are conffiles (I
think), the next upgrade of system which gets the feature fixed will
not affect the unit files where usage of that fealure was disabled.

On yet another hand (the 3rd?), I suppose by the time Stretch comes out,
we should have no units making use of RestrictAddressFamilies in the
packages Debian ships, and the problem then affects only non-Debian
packages and the units created by hand.


On a side note, one of the things I sold on of the Go programming
language is the stance of its developer on the warnings produced by the
compiler: it produces none.  To cite the relevant bit of the FAQ [1]:

| There are two reasons for having no warnings. First, if it's worth
| complaining about, it's worth fixing in the code. (And if it's not
| worth fixing, it's not worth mentioning.)  Second, having the compiler
| generate warnings encourages the implementation to warn about weak
| cases that can make compilation noisy, masking real errors that
| should be fixed.

I personally couldn't agree more but OTOH I'm aware that this is merely
a PoV and different PoVs do exist, hence just voicing mine ;-)

1. https://golang.org/doc/faq#unused_variables_and_imports