[ On Fri, May 16, 1997 at 11:51:36 (-0400), Jay Denebeim wrote: ]
> Subject: Re: require_files undesirable behavior
>
> I can't see how checking for a file's existance is a security breach. If
> it's simple enough to become root again at that point, I'd say go for it.
> I, for one, am uncomfortable with people being able to see into my home
> directory, and I'd prefer you be root at that point.
If the intent is to open the file (even only for reading in some cases,
such as needing to know if not only the file exists, but whether a given
non-privileged user is to be permitted to read it), after the file has
been determined to exist, then the tricky part is avoiding race
conditions.
The only sure way of doing so in a secure manner that I'm aware of is to
first blindly open the file for reading as root and fstat() the
resulting descriptor, if there is one. Then you need to fork a child
process that becomes the un-privileged user in question. It must then
also open the file in question and fstat() the resulting descriptor, if
there is one. Assuming both fstat()s succeed the resulting data
structures must be compared and found to be identical (except for the
time components, and possibly the size). If we get this far then the
child can return a zero exit status and the parent (still running as
root) may proceed to safely use the original descriptor.
If the file was to be opened for writing the algorithm is a little
more complex of course, but I think you can see where I'm going....
Looking at sub-components of the pathname before actually opening the
file can be very tricky and leads to even more potential race
contidions. There's no way in unix to say "lock the components of this
pathname" so that atomic tests and operations can be done on some or all
of them.
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
