[Pkg-nginx-maintainers] Bug#816446: (no subject)

[Michael Lustfield]

nicoo: I'll apologize up front for my immediate response. I'd not looked at
this closely enough and made an incorrect assumption. I've finally found the
time to look at this a bit more closely.


> From: Moritz Muehlenhoff <jmm at debian.org>
> systemd is the default init system since jessie and we cannot limit
> features used in init scripts to the least common denominator. In fact
> we already have a lot of feature disparaties with sysvinit not 
> providing many features present in systemd.

I don't care if it's the default. It's not the only init system supported by
Debian and breaking things for everyone else is unacceptable. Additionally,
there are a very large number of users with non-systemD servers and many
organizations I've worked with have expressed interest in avoiding it as long
as possible. They've quoted this type of action as one of the primary
motivators for that decision.

Yes, we can add confinement features. No, we will *NOT* break support for other
init systems.


Now...


Looking at this more closely, PrivateTmp and PrivateDevices shouldn't cause
issues.


> # Prevents access to /home, /root and /run/user
> ProtectHome=true

I actually like this idea, but... we have a *LOT* of "administrators" out there
that assume placing applications in /home/<web>/ is the standard way of doing
things. Once this update reaches them, their applications will stop working
correctly. Even setting /home to read-only is going to generate an enormous
amount of breaking.

I agree that nobody should ever put web applications in /home, but it's a
common practice. Are we ready to break their setup? Are we ready to deal with
the continual fallout?

I'm wondering if ProtectHome=false would be better with a comment above it
explaining the benefits of =true/read-only.


> # Makes /usr, /boot and /etc read-only
> ProtectSystem=full

This has the potential to have the same problem as above. I know some web
applications like drupal install configuration data to /etc, but these are
typically symlinks for convenience. I'm not sure how applications will behave
and would hedge toward =true for this setting.

It's also worth noting that, when configuration management tools are used, web
applications are typically dropped into /srv or /opt. These will also need to
remain accessible, as will /usr/share and possibly others.


Anyway, this is all for continued discussion.


As for roll-out, I would prefer include this with #822792. If this is going to
break anything, keeping the roll-out schedule to that bug should help make sure
I break everything that can be broken before releasing for public
consumption. ;)

If anyone is interested in helping expedite that, I'm not gonna argue!

-- 
Michael Lustfield