On Tue, 13 Jun 2023 at 20:51, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > That paragraph is in the context of StateDirectory= and > > RuntimeDirectory=. These are unit files options, so it's up to > > alternative init systems to provide alternative and integrate them in > > the (eventual) init script, just as they are defined in the systemd > > unit. I've mentioned those explicitly as you indicated earlier in this > > thread: > > Ah! Sorry, I did inded not understand the context correctly, and should > have just not replied until I had a chance to read the context. That's my > fault. > > I agree with this statement with respect to systemd unit features. This > is a consequences of the fact that units are the preferred daemon > configuration and package maintainers are allowed to use its features (GR > 2019-002). We should be encouraging them to use those features correctly > and documenting how to do so, but that necessarily means that init scripts > for use with other init systems will need to provide a version of the same > feature in some other way. We have had several GRs on this topic, and > Policy does need to follow the outcome of those GRs unless someone > overturns them with another GR. > > That being said: > > > Again, the rationale is: when there is a strong ownership model tied to > > an individual service those are best as the lifecycle and permissions > > are handled, when there is no owner or no specific owner or particular > > metadata requirements then tmpfiles.d are best. > > I still am curious if it's safe to configure the same files in both > tmpfiles.d and in the unit file, because it would make it much easier for > those who want to support other init systems to do so.
As long as they both do the exact same thing, the one that runs last is a no-op, I don't believe there would be any issue. But they have to be kept in sync, not only w.r.t. directory name, but metadata too (ie: ownership). See it this way: if the features provided by tmpfiles.d and unit files (w.r.t. directories) were on a venn diagram, there would be an intersection, yes, but there would not be a complete overlap. There are things tmpfiles.d can do, that StateDirectory= and friends cannot, and vice-versa. In other words, for your stated goal of helping those who want to support other init systems, it would only cover a subset of cases - and these are real world cases, there are many services out there making use of these features. We cannot be restricted, in terms of unit files options, to what tmpfiles.d can provide, as that is not realistic. This is why I added that paragraph, indicating that other init systems should provide equivalent functionality (and bear in mind I am not a policy guru, so if 'should' is the wrong word I can change as needed, it's perfectly fine as far as I'm concerned if other init systems simply say, run everything as root and forget about security. It's their choice what features they provide and I was not intending to force them to do anything.). Kind regards, Luca Boccassi
