> Linda Walsh wrote:
>
> > [...]
> > What would you see the behavior being if process 'x' is chroot'ed
> > to directory 'y' and you blocked access to a directory above it's root?
> > Would the access checks still be done to the root of the filesystem or
> > just the 'root' of the process?
> >
> > -linda
> >
> > --
> > Linda A Walsh | Trust Technology, Core Linux, SGI
> > law@sgi.com | Voice: (650) 933-5338
>
> How is it done now? If some process chroots to /dir1/dir2, and tries to access
> /dir1/dir2/file, does the access succeed or fail after a "chmod 000 /dir1"? Is the
> current behaviour not incorrect, too?
I think you are misunderstanding.
If it chdir()'s then access _should_ fail[1].
If it is chroot()'d then it wouldn't be able to open() via. that
scheme anyway.
...but apart from all these it's slower it's not arguments, as a sys
admin I _know_ that for permissions on a name[2] I have to check the file
itself and the previous directory[3], if anything changed that simple
permission model to a complicated one where I have to check _every_
dir back to the root then it's time to get out vi and diff IMO[4].
[1] Logically, I haven't checked this but I doubt there is any magic
there if dirname() == $cwd.
[2] A name == a vfs object, be it a file, a socket, a dir, etc.
[3] Not counting hard links
[4] From what Ted's said this isn't going to happen, so i'm happy, I'm
just giving you another reason why Ted is right :).
-- James Antill -- james@and.org "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy.- 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/