I guess the simple answer to Adam's question: if there is somewhere we advertise that the permissions on a file are the intersection of the permissions granted by the ACLs on all directories above it in the volume, we should fix that. I am aware of no such claim being made. A reference to such would be appreciated.
On Mon, Jan 18, 2010 at 3:11 PM, Derrick Brashear <[email protected]> wrote: > On Mon, Jan 18, 2010 at 3:07 PM, Andrew Deason <[email protected]> wrote: >> On Mon, 18 Jan 2010 14:32:56 -0500 >> Derrick Brashear <[email protected]> wrote: >> >>> > Does this mean that if we have a setup like this: >>> > >>> > mkdir foo >>> > fs sa foo system:anyuser rlidw >>> > mkdir foo/bar >>> > fs sa foo system:anyuser none >>> > >>> > That anonymous users can access "foo/bar/", so long as they know >>> > the FID for "bar" -- either because the fourth command wasn't >>> > executed immediately after the third, or else because they were >>> > simply patient enough to guess it? >>> >>> Doesn't mean that in the slightest. Note that foo/bar/ is a directory >>> and not actual data, but, the case is the same regardless. >>> Permissions are enforced for every vnode. Look at >>> Check_PermissionRights in afsfileprocs.c >> >> I'm not sure if I'm misunderstanding you or Adam... because, yes it does >> mean that. You can access files in foo/bar/ if you have the rights on >> foo/bar/; the rights on foo/ do not come into play. Right? > > Correct. > > If you're bored, you can read every FID you can read. Just read them > one at a time, starting with 1. > > Don't want to let someone read something? There are these ACLs.... set them. > -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
