Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
Oystein Viggen <firstname.lastname@example.org> writes:
> I have a patched ftpd-BSD that does just that. Started by root, it will
> setuid() to user ftp, retaining CAP_NET_BIND_SERVICE (open ports below
> 1024) and CAP_SYS_CHROOT (obvious, no?). [...]
> Would this be exactly what you are talking about?
Sounds similar, except that it would be nice to have even narrower
capabilities, like opening a particular low port and no others.
> > Using seteuid requires root privileges (real uid = 0). So that's out
> > of the question for a hurd process running with an empty set of uids.
> Can't you use the wonderful /servers/password for this?
I don't think so. The passwd only hands out uid:s if you give it the
correct, cleartext, password, which you don't want to have around. At
least that's my current understanding of what the passwd server does.
> No, root has all or mostly all capabilities, and normal users have none,
> but if you start a process as root and do a prctl(PR_SET_KEEPCAPS,1),
> you can setuid() without dropping any caps, after which you as the new
> user can drop any unneeded caps.
Thanks for the explanation.
> As I understand it, hurd will check if your uid is 0 to see if you are
> allowed to perform certain operations? Does the microkernel/server
> architecture of the hurd make it difficult to have capability checking
> more akin to linux?
Most of these checks are done in the proc server and the filesystem
servers, I think. The "privileged ports" check is probably in the
pfinet server, though. The current job of most of these servers is to
implement posix semantics, with a few natural extensions. If you hack
your own servers, possibly delegating some of the work to the
"standard" servers, I believe you could do interesting non-posix