Re: permissions not honoured by /bin/pwd aka getcwd

From: Horst von Brand (
Date: Sat Feb 26 2000 - 11:19:14 EST

"Peter T. Breuer" <> said:
> "A month of sundays ago Horst von Brand wrote:"
> > "Peter T. Breuer" <> said:
> > > "A month of sundays ago Horst von Brand wrote:"
> > > > Peter Chubb <> said:
> > > > > The posix.1 spec for getcwd says this:
> > > > > (section 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).

No. "I don't care where you live" is not the same as "I think you live in
Greece". Note they say "if the condition is detected", not "shall check for
the following condition". I understand that to mean that if in the course
of business you happen to stumble upon the condition, you must say so in
the way stated. If you don't care, you won't notice and so you have nothing
to report.


> > 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.

"Stop the whole system, a getcwd(3) is going to start".

> > 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.

Better don't. It is just not worth it.

> > 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.

And said processes could very well do a getcwd(3) as first order of
business in order to be able to cheat later on.

What does make sense is root starting a process as an ordinary user in a
directory where the process isn't allowed to x one of the ancestor
directories. What could said process ever learn this way that might
compromise security? It could leak info to say, /tmp by just calling it by
name in any case.

I understand the idea of "need to know", but IMHO if a process cares for
its CWD it has a need to know. And if this is a real no-no, you probably
have half a dozen other reasons to put it in a chroot(2) jail anyway.

Horst von Brand                   
Casilla 9G, Viņa del Mar, Chile                               +56 32 672616

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:15 EST