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

Eh? Yes it is. Try again, this time remembering the elementary logic
that I'm sure you're good at! You are forgetting the zero case. Both
"I don't care where you live [and therefore I don't have any opinion
on the matter]" and "I think you live in greece" are covered by "I
will send postcards to where I think you live", not by "I will send
postcards to where you really live". That was the distinction I was
making.

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

Both of those are (2). I.e. the specified trigger is that the code thinks
the condition is true. It just so happens that under the "I won't look"
policy, the code will never think the condition is true. But both
situations are covered by the "thinks it's true" description. That's
all I was saying.

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

Block the return until there are no relinkings underway.

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

Yes. What happens if one renames elements of the path under the feet of
a process in unix, btw? I asssume the process ends up with an invalid cwd
and starts having a lot of trouble going anywhere.

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

True. There is clearly an information leak caused by the linux
path cacheing mechanism there. But the process has no way of knowing if
its information is still current.

I almost feel that a process should die if it loses the right to be
where it is, through renaming or re-perming of components of the
path to its current directory.

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

It probably should never have known (the absolute path to) its directory.
It was none of its business.

I suspect that removing the whole idea of absolute paths would solve the
chroot problem and others once and for all. You should only be able to
see daughter directories, and you should indeed (as in classical unix)
be forced to beg for information about your ancestry.

That would require every user home to have symlinks to /usr and /bin
and /lib :-).


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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.039 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site