Re: (reiserfs) Re: NFSv4 ACLs (was: ...ACL's and reiser...)

From: Hans Reiser (hans@reiser.to)
Date: Thu Aug 10 2000 - 08:19:23 EST


Horst von Brand wrote:
>
> Xuan Baldauf <xuan--reiserfs@baldauf.org> said:
> > 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?
>
> > 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?
>
> No chroot(2) needed, just a chdir(2) to make your point. And as always,
> permissions are checked when they are used (i.e., to go into /dir1/dir2,
> they are checked at _that_ point in time). If they are changed later
> doesn't matter. A bit surprising perhaps, but the only sane (and efficient)
> way of doing business.
> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

No, Linda is right, the issue is deeper. I think the answer is that only inheritance setting not
inheritance resolution is affected by chroot (though when we implement symbolic inheritance that
will be affected by chroot).

There are two types of inheritance, traversal and pulled, where traversal means you specified that
everything below some directory inherits something, and pulled means that you specified that a file
will inherit from somewhere else. Traversal inheritance should have no effect on processes that
have already chdir'd to below. Think of this as being the definition of that semantic, you are not
changing the value for everything below, you are changing the value for everything that goes through
you to get below.

Thanks Linda, your question forced me to define things much better.

Hans

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



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