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
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
