Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: permissions not honoured by /bin/pwd aka getcwd | Date | Sat, 26 Feb 2000 18:02:59 +0100 (MET) |
| |
"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/
| |