Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
On Tue, Jun 05, 2001 at 09:03:31PM +0200, Oystein Viggen wrote:
> It also seems that root is still god and can do whatever he wants, also
> killing these processes, but two different rmauth'ed oysteivi's can not
> frob each others processes.
Yes, uid == 0 usually overrides any other checks.
[...]
> The strangeness kicks in when the files are created in /tmp. No matter
> who I rmauthed from, the files will appear owned by user and group root
> with the default umask. This means that I can 'cat > /tmp/somefile',
> and actually get what I want in there, but I will not be able to open
> this file for writing again, as it is now writable only for root.
What else could it do, without further support in the filesystem server for
this? :)
> It seems to me that implementing this in the filesystem would really be
> a PITA, as you need to add the concept of files owned by the nameless
> non-user while still taking care of the login groups.
That's correct. You'd have to create new temporary user ids on the fly
or so.
> > The programs can access the filesystems through the fourth set of access
> > bits. By default, they are the same as the bits for "other".
>
> Are these supported in the current ext2fs implementation, or do we need
> to fix both that and the user space tools?
It is already supported (and an API is there, see bits/stat.f (S_IUSEUNK
etc). We also have an "author" extension.
Implementing support for this in ls, chmod etc is a very old item on the
TODO list.
> > This way, you can actually do something useful.
>
> I'd argue that without the option of keeping some privileges, much like
> capabilities in linux, this would be of limited use for things like
> network servers.
Of course. Luckily, every user can write new servers (proc etc) which
implement new authentification protocols and run them ;)
I thought about first opening a socket and bind to it, then drop uids.
That's not so good as running without any ids in the first place, but
better than keeping those uids around, isn't it?
> A last note: I could not find the program getlogin anywhere. It's not
> in the hurd package at least. Is there any other way to list process
> groups or any place where I can get this program?
I meant getlogin() in glibc, sorry.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: