lkml.org 
[lkml]   [2000]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: permissions not honoured by /bin/pwd aka getcwd
Date
From
"Peter T. Breuer" <ptb@it.uc3m.es> said:
> "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).

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 vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans