[OpenAFS-devel] Re: [AFS3-std] Re: "l" permissions are not actually weaker than we're telling people

[Derrick Brashear]

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 <shadow@gmail.com> wrote:
> On Mon, Jan 18, 2010 at 3:07 PM, Andrew Deason <adeason@sinenomine.net> w=
rote:
>> On Mon, 18 Jan 2010 14:32:56 -0500
>> Derrick Brashear <shadow@gmail.com> wrote:
>>
>>> > Does this mean that if we have a setup like this:
>>> >
>>> > =A0 =A0mkdir foo
>>> > =A0 =A0fs sa foo system:anyuser rlidw
>>> > =A0 =A0mkdir foo/bar
>>> > =A0 =A0fs 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 th=
em.
>



--=20
Derrick