Subject: Re: utmp file format change
To: Andrew Brown <atatat@atatdot.net>
From: R. C. Dowdeswell <elric@mabelode.imrryr.org>
List: tech-userlevel
Date: 09/28/2001 20:37:56
On 710408911 seconds since the Beginning of the UNIX epoch
Andrew Brown wrote:
>

>sort of an analogue, but different because instead of having an
>arbitrary pointer to some piece of data, you have a file descriptor.
>i think that doing it using the normal file system backing it would be
>easier.

Sure, it may be easier to do is fs-backed.  But, if you do it
anon-backed, then we could fix mfs to just index into a list of
these guys that live in the buffer cache and swap.  I.e. we could
leverage the work to make our mfs not have the problems that it
currently has (i.e. an extra copy when accessing data, and the fact
that it uses/swaps out space that isn't actually allocated.)

>as for flink(2), no.  flink(2) would be a terribly bad idea.  consider
>that when opening a file, *all* the permissions on *all* the inodes in
>the path to the file are considered.  if you were able to get some
>process to hand you an open file descriptor to some file somewhere
>that relies on being protected by permissions in the path and you were
>able to flink(2) it to some arbitrary name, you could bypass the
>permissions set that had been established.

Hmmm, I did not consider that.  Of course, once you've handed the
fd to another process like that, it could simply hand the fd out
to anyone who asked for it, circumventing the permissioning in a
very similar way.  The big problem would be if you had a file with
group or other write permissions set, then the second process could
link it to the fs and re-open it with elevated permissions, which
would be a significant minus.  So, scratch that idea for now.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==
 == Ponte, Inc.                                    http://www.ponte.com/  ==