On 18.04.2017 12:21, Alessandro Selli wrote:

> Again, as far as I understood what Enrico Weigelt wrote, the monitor
> does not want to know the user:group the daemons runs under, it needs to
> *set* them to the appropriate values when it launches the daemon to have
> them reflect config file settings or local policies.

Right. In that case, srvmgt_droppriv() would essentially do nothing
(execpt perhaps some logging note).

OTOH, we might have situations where the daemon needs to do some root
operations first (eg. opening privileged sockets) before dropping privs.
In that case the monitor/init can pass the target uid:gid via env, so
it doesn't need to be configured within the application.

> Again, the relevant info is supposed to be set in config files. The
> user:group the daemon must run under is not up to the daemon itself,
> they are set in config files, either the deamon's or the monitor's.

Exactly. My approach also gives the choice of passing that from the
init/monitor, even if the application needs to to the setuid() stuff
itself.

At that point we can consolidate all these individual assignments from
dozens of separate configfiles to one place, somewhere within the init
system / service monitor (which ever the operator might have chosen).
In the end, the application doesn't even care about that anymore.

> Again: if you do not want to take advantage of the monitor's policing
> capabilities, don't use them.

Exactly. And ease deployment and configuration for both cases, I'm
just proposing to move these things out of individual applications and
consolidate them in one point (the library). If one doesn't want any
monitor, then he'll just install a minimalistic version, which wouldn't
be much more than dummies or thin wrappers around things like daemon().
Anybody can choose his preferred implementation easily, w/o ever
recompiling or even patching.


--mtx