Closing files after fork

Achim Gratz Stromeko at
Thu Aug 26 18:42:43 UTC 2021

Hal Murray via devel writes:
> The close-everything code either has to skip the files it needs or
> reopen them.  That requires keeping track of the files it needs which
> isn't something most programmers do.  In our case, that was buggy.

This is a general thing you have to do do in a daemon that drops
privileges.  Let's say you needed those privileges to open a device or
privileged network port, then when dropping to a non-privileged state
you'd need to keep these handle(s) open, but close any other files the
original process might have open for whatever reason.  You might indeed
have open files that your process didn't actively open, but inherited
from a shell script or however it got started originally.

While you could say it's not your problem (shoving it to whichever
method does the startup for you, often systemd these days), defense in
depth would suggest you close any files you don't need or even have no
idea what they are.  In the same vain you're supposed to check that the
real, effective and saved ID actually changed to what you were intending
when you were dropping to the unpriviledged user/group.

You don't need extra privileges on startup to open files if they are
owned by the user that you are started under and if the system provides
that user/group with the capabilities to open the NTP network port.  But
not all systems are set up that way (or at least you can't assume they

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:

More information about the devel mailing list