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 <j...@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
