[PVFS2-developers] Re: Limit a particular pvfs2 client's access to data

[Rob Ross]

Murali Vilayannur wrote:
> Hi Rob,
> 
>> Specific question: why did you need to
>> add checks in the set-attr state machine in addition to prelude, but not
>> other state machines?
> 
> Hmm.. Can you tell me which other state machines I need to add this stuff
> in?

It was just a question :), which you answer quite nicely below.

> Prelude state machine does all the permission checks, and any
> uid/gid translation must be done prior to doing those checks.
> Set-attr stores the permissions based on the credentials sent over the
> wire, and any uid/gid translation must be done before it stores it on
> disk. (For some reason, setattr does not make use of the credentials
> field in the request but a duplicate copy in req.setattr.attr.owner,gid,
> dunno why. Therefore, the prelude changes were unfortunately not
> sufficient for the set-attr case)

We probably want to keep this.  It's useful for (for example) someone 
with root credentials to set the attributes to indicate some other 
owner.  Actually, what semantics are you applying here?

> I was hoping that all cases would be covered with these 2 state machines
> changes alone. Unfortunately, there are still some permission denied cases
> when using the utimes() system call for the AllSquash case. I havent yet
> fixed that, since it involves local kernel/acl changes I think.

That's weird.  I would think that all this could be done on the server side?

>> Have you thought about how we might do this on a per-client basis, and
>> if so, how that might change both how you do the checks and how you
>> describe things in the config file?
> 
> Good point.
> How about something like
> <ExporOptions>
> ReadOnly yes(list of aliases)
> RootSquash yes(list of aliases) and so on...
> </ExportOptions>
> If no aliases are specified. then it is assumed to be the case for all
> clients..
> Checking it would involve that I somehow get the BMI address
> information for comparison with the filesystem export cofiguration and
> disallowing or allowing checks based on that. I can look at this and send
> a patch later today for people to comment, if you like the above approach
> or if you wanted it done another way

What if we did this as part of the <Security> options?  Could we apply 
the transformation to the credentials around the same time that we 
decide if we want to accept the connection at all?  Either way, it would 
probably be good to keep all this client selection/export related stuff 
in the same place?

Rob