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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
