"A month of sundays ago Horst von Brand wrote:"
> "Peter T. Breuer" <ptb@it.uc3m.es> said:
> > "A month of sundays ago Horst von Brand wrote:"
> > > Peter Chubb <peterc@aurema.com> said:
> > > > The posix.1 spec for getcwd says this:
> > > > (section 5.2.2.4)For each of the following conditions, if the
> > > ^^^^^^
> > > > condition is detected, the getcwd() function shall return a value
> > I don't speak standard either. I imagine that "is detected" could
> > either mean
> >
> > 1) holds
> > 2) the code in question thinks it holds
>
> (1) is out, as "is detected" ==> "holds", but not the other way around. And
> there is also (3), "The code doesn't care, so it doesn't check" ==> Won't
That's (2).
> ever detect anything, and never complain (which is exactly what Linux does
> now).
>
> > Which? Assuming that the code can't think it holds when it doesn't and
> > still be posixly correct, then (2) is a subset of (1).
So (2) in this case is the empty subset. Fine.
> AFAIKS the language doesn't say explicitly it has to make up its mind
> (i.e., check always), so it can get away with not doing useless checks, or
> keeping track of chdir(2)'s and cache the result. Note that to be correct
> here, you would have to lock the whole path up to /, and the result is
To prevent changes while answering? The alternative is to not answer
while changes are still ocurring.
> useless anyway because I can just chmod(1) the directories just after the
> getcwd(2).
I can dimly imagine basing a file-system locking mechanism on chmod of
the parent dir.
> Again, is there any sensible reason to deny a process the knowledge of its
> CWD?
Vaguely, "security". Perms changes by root don't affect processes
already inside the barrier.
Peter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:15 EST