Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter <sjr@debian.org>]

Hi,

On Mon, Aug 19, 2019 at 09:55:22PM +0300, Andrei POPESCU wrote:

> > I hope we also support the case where we ship a restricted unit file for
> > non-systemd and a unrestricted unit file for systemd.

> Would there be cases where the "restricted" unit file is using options 
> not present in the "unrestricted" unit file, and if yes, is that case 
> worth supporting?

TBH, I'd expect these to diverge quickly, because in the SysV world,
daemons first set up stuff they need privileges for, then drop the
privileges and go into the main loop. In order to move the "dropping
privileges" part into systemd, the initial set up must be part of systemd
as well.

This already works for sockets, which can be passed as file descriptors
easily, but will be a lot more difficult for configuration files (in case
the service is supposed to run in a chroot) or key material for SSL, so if
people actually want to use systemd to manage privileges, they will need to
add appropriate interfaces that allow an otherwise isolated service to
perform privileged actions during a well-defined time period at startup,
ending with the time the service reports itself as running.

This only makes sense if the access control for this interface is
finer-grained than what the kernel provides, otherwise we're no better off
than before, so there'd have to be appropriate parameters to configure that
access control.

I also fully expect DLL-based services to pop up rather sooner than later,
because seccomp or syscall filters cannot be set up as tightly as needed
before an execve(). These will probably extend unit file syntax quite a bit
as well.

All of these extensions aren't useful for daemons that set up their
execution environment themselves, but some daemons expect to be called in a
restricted environment already, and we need to be able to distinguish that.

Last but not least: We currently do not have a normative definition of an
"unrestricted" unit file. I'd be very unhappy if we adopted a "restricted"
definition into Debian Policy without also defining the "unrestricted" set
at the same time, otherwise "unrestricted" becomes short for "unrestricted
by Debian Policy".

> It seems to me like a unit file to SysV translator should just ignore 
> the options it doesn't support, so it wouldn't be necessary to have two 
> different unit files.

Init scripts fail when they encounter an unknown command. A useful
replacement should do the same.

   Simon