There is no “tried and true” method to drop privileges after you’re done with them; this has been a constant source of headaches and security issues for pretty much any app that needs to be started as root in order to xxx (eg bind to a low port, if we pretend that’s the only way) and then drop said privileges.

The solution is almost always to use (or add) kernel constructs that would obviate the need to elevate in the first place, but they generally aren’t fine-grained enough so on paper it looks like dropping privileges makes more sense, though in practice it might turn out to be the bigger mistake.

The more or less default way how to accomplish this (ie. setuid(1)) is immune to that issue. On the other hand it does not really drop privileges in the modern sense as the process can regain them at any time because it is still owned by root.

No, a privileged process can't regain privileges after setuid(2).

Drop them in a subprocess, read the file and send the data to the parent?

logged in into one of my machines via ssh. The daemon is running with all uids being 0 and full capabilities. Don't see how that would be dropping any privileges. On the other hand

* The machine has no desktop user at the moment

* The program was patched on 04-Nov, I guess addressing this issue.

The program only temporarily drops privileges while reading the user-supplied file. The rest of the time, it would have all uids as 0 and full capabilities.

I guess you could fork first?

Fork then handle child/exec error codes appropriately.

Right, if the child runs as the user, the parent still running as root can reliably handle the situation that the user killed the child.

Don't remember having seen that. Well, sshd does it, but for more obvious reasons than handling signals.

Forking does not affect the possibility to receive signals, does it?

seteuid(uid) if you want to revert later.