On Mon, Jul 15, 2019 at 12:31:21AM +0200, Stefan Sperling wrote: > 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). Yes, that was my point.
> > 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). This could work, but I have not idea of how it would look like, yet. > 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. I concur. > 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. As already said, this is not already possible, but it still is a good reason to prefer our framework (as the majority of user setting rc.d scripts in ports already does).
