>> >CERN httpd runs fine in a chrooted environment, and is perfectly willing to
>> >relinquish root privs (both real and effective) once it's opened port 80.
>> This is the key word. It has to run as root for awhile. This makes
>> me nervous. I'd rather have a program that opens port 80, chroots, and
>> invokes httpd.
Httpd does very little between startup and the setuid(). This part of the
code is simple and easy to read (regardless of what you could say about all
the rest of the code).
ca (Mike Shaver) said:
> Even just changing uid right after the bind would be better.
> I know NCSA waits until after the accept *and* the logging to change, which
> is OK, but still not warm and fuzzy.
CERN supports setuid in the parent (immediately after binding port 80)
using the ParentUserId and ParentGroupId parameters in the config file.
The thing has lost root privs by the time it accepts any incoming
connection, or opens any file other than its config file and logfiles.
> Actually, I'd rather make chroot() and <1024 priveledges be
> contingeant on being in group "daemon" and never run these servers as
> root as at all.
This would be nice for reserved ports (especially for things like rcmd!)
but anybody who can run chroot can become root, so it doesn't really save
you anything to reduce the privilege level needed to run chroot. (I don't
like systems that pretend to add security by setting up all sorts of
different privelege levels like bin, auth, cron, etc, all of which are
equivalent to root since they can be used to become root at any time.)
Tom Fitzgerald 1-508-967-5278 Wang Labs, Lowell MA, USA fitz @