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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
