Proposal for next steps for systemd-related policy

[Russ Allbery <rra@debian.org>]

Hi all,

This is a tentative proposal for next steps from a Policy standpoint given
the result of <https://www.debian.org/vote/2019/vote_002>.  I thought it
might be helpful to lay out a possible way to sequence the work.

1. Downgrade the requirement to include an init script in a package with a
   systemd unit to "encouraged."  This is the direct outcome of the GR, so
   I think we should make this change before the next normative upload,
   since there's no point in Policy being inconsistent with the GR result.

   I think there's some discussion to be had here about whether the
   correct level is "encouraged" or "optional."  I'd also like to revise
   and merge my change that adds "encouraged" first, although if we decide
   "optional" is correct, that sequencing is, well, optional.

2. Do nothing further before January 6th.  It's still the holidays, and
   subsequent steps are going to require some discussion, and I think it's
   worth taking a breath.

3. Start a discussion on debian-devel to see if we can come up with some
   idea for how to declare dependencies on availability of system
   services.

   My thought process here is that while the GR permits packages to start
   using systemd facilities directly, doing that without somehow declaring
   that requirement in package metadata seems likely to cause bugs and
   upgrade issues, so we should try to provide some better facilities.  I
   think there's an obvious gap here where we need a mechanism to declare
   a dependency on a system facility (as distinct from a package that may
   be installed but not running) such as tmpfiles.d, sysusers.d, the
   ability to rely on DynamicUser without creating a user for that purpose
   in maintainer scripts, systemd D-Bus facilities, socket activation, or
   so forth.

   This would be a way to provide better UI when someone on a sysvinit
   system tries to install a package that requires a systemd facility (via
   an upgrade scenario, for example).  It also exposes in the archive what
   facilities are blocking use of packages on non-systemd systems, and
   thus provides a prioritized list of work for anyone who is pursuing
   exploration per paragraph two of the GR.

   This obviously is going to require some hashing out, and may well
   require support from the dpkg, apt, and aptitude teams.

4. Parallel to point 3, start fleshing out Policy recommendations for best
   practices for systemd units.  Some initial candidates for security
   hardening:

   - DynamicUser (*without* removing useradd, see below)
   - ProtectSystem
   - ProtectHome
   - PrivateTmp
   - PrivateDevices
   - SystemCallFilter

   We probably also want to recommend Type=notify where possible and
   Type=exec where not, over Type=forking, when the daemon supports that.
   OOMScoreAdjust may also be worth setting some policy around.  We
   should, of course, have an open discussion of other things that people
   would like to see documented as best practices.

   These are chosen because they only affect the unit file and don't add
   any additional assumptions on the availability of other services.

5. As the outcome of point 3 concludes, start documenting use of other
   desirable services that would allow simplification of Debian packages
   and allow package maintainers to use those services rather than the
   ones that Policy currently requires.  My personal priority list looks
   like (roughly in order):

   - DynamicUser without useradd of a system user
   - tmpfiles.d
   - sysusers.d
   - Timer units
   - Socket activation

   but we should have an open discussion of what other facilities people
   think Debian would benefit from.  I think we should prioritize the
   cases where it would be relatively straightforward for other init
   systems to provide the same functionality; for example, tmpfiles.d and
   sysusers.d can be supported by simply arranging to run the relevant
   systemd binaries at appropriate times.  DynamicUser is a bit harder,
   but I think the minimum functionality to let the package keep working
   could be added to start-stop-daemon or some wrapper that it execs.

   As time goes on, we'll get a better feel for how much work folks will
   be doing going forward on supporting other init systems, and thus on
   how quickly we should move versus giving them time to determine how
   they want to support equivalent functionality.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>