Hello Russ, On Sun 29 Dec 2019 at 10:47am -08, Russ Allbery wrote: > 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. Thank you for writing this. > 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. Under the new description of these words in #944920, I think we would have to use 'encouraged'. That new text says that 'optional' is meant to be used purely for clarificatory purposes, but incorporating the result of the GR into Policy would not be a matter of clarifying something else said in Policy, so far as I can tell. I think it's useful for 'optional' to be reserved for its clarificatory role. > 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. Indeed, the GR discussions made it clear that this is something we need. > 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. This would be very cool to have in Policy. > 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. This is a sensible approach. We clearly need progress on (3) more urgently than on (4) and (5), but I am not sure there is any sensible ordering of (4) and (5), so let's not worry too much about that. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature