On Sun, Jul 14, 2019 at 10:41:33PM +0100, Stuart Henderson wrote:
> I think this is likely to work for git-daemon but isn't always going
> to work in the general case (sometimes a daemon needs to bind to port <1024,
> for example). So maybe it's better if we come up with a more general thing
> that can be copied and pasted (after all rc.d/gitdaemon is going to be
> present on many users' and devs' machines so it's not a bad place for
> a reusable example).
I see what you mean, but I think it makes sense to have porters deal
with this on a case-by-case basis. Every upstream software has different
requirements and edge cases. In some cases we might decide we want to
limit possibilities provided by upstream (e.g. upstream might be fine
with using a privileged port by default, while we aren't), in some
cases we might trust upstream code to do things right.
Encouraging copy-pasting in this area might result in porters not
considering all their options carefully.
> Hardcoding a username in $daemon won't always work, somebody might need
> to run as a different uid.
My patch still alllows for that. It doesn't tweak $daemon. Rather, it
sets a reasonable default value for $gitdaemon_user which can still be
overridden if desired.
> Another approach might be a custom rc_start
> that starts the daemon as root and adds --user=${daemon_user} etc to the
> command line.
I don't see why we should trust this --user option and give upstream code
a window where it runs as root until it decides to switch UID, if rc.d(8)
can make the entire program start out with an unprivileged UID from the
beginning.
