Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
Quoth Niels Möller:
> I'm thinking of anonymous ftp service only. In my book, changing the
> effective uid but keeping a root real uid is *NOT* to "drop
> privileges".
More like "obscuring access to privileges", right.
> I'm comparing with hacks like having a www-server start with root
> privileges, bind port 80, and then change the *real* uid to
> nobody. Like the "permenently change uid" option in Roxen.
This is nice and proper. Apache should be doing this.
> With a decent capabilities feature like we're discussing here, you
> would run an anonymous ftp server with the special capability of
> making connections with port 20 as the source port, and *no* special
> privileges besides that. In particular, the process should not run
> with the capability of reading all users' private files. That's one
> thing you can't do on a traditional unix. I'm not sure if you can do
> that with linux' capabilities.
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?). The latter is dropped after
you stop needing it, and the former is only kept in the permitted
capability set and only made effective when it's needed (when you would
seteuid(0) in the unpatched version).
Would this be exactly what you are talking about?
> 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 see. If I understand you correctly, capabilities in linux only apply
> to root processes. You can run a process as root but with most
> capabilites stripped away, and switch back and forth between root euid
> and the euid of your choice (assuming you have enough capabilities to
> call seteuid).
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.
> That's not at all how I think about capabilities. A "capability" is
> the abaility to do certain things on the system. When logged on on the
> Hurd, by default you have the capability of authenticating as a
> certain user (this is represented as a port right to the auth-server).
> And when you apply this capability to proc and filesystem servers, you
> get all capabilities of that user, like reading and writing certain
> files, controlling certain other processes, etc.
This differs a bit from Linux capabilities. There, when logged on as a
normal user, you have no capabilities at all. Capabilities there is
just a way of splitting root access up into smaller parts. The kernel
never checks if your uid is 0 to see if you are allowed to do stuff, it
just checks if you have the needed capability.
(Of course if you have uid 0, you can edit any file you own, so dropping
capabilities while not dropping uid 0 makes little or no sense.)
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?
Oystein
--
If it ain't broke, don't break it.
Reply to: