Re: Limit a particular pvfs2 client's access to data
rross at mcs.anl.gov
Thu Dec 8 11:59:50 EST 2005
Murali Vilayannur wrote:
> Hi Rob,
>> 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?
> If rootSquash was specified in the exports, then transform the uid/gid (if
> it was 0) to the anonuid/anongid.
> If AllSquash was specified in the exports, then transform any uid/gid to
> the anonuid/anongid.
Does it even make sense to allow a nobody user to chgrp/chown a file?
Do you need to fix those values, or just let the setattr fail?
>>> 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?
> So there is a whole bunch of permission checks that dont even hit the
> server (well other than the getattr to get the modes etc).
> We have been bitten before in the pvfs2_permission checks, and it looks
> like something might be broken again in that code, since I get an EACCES
> error with the utimes system call.
> So it is a minor thing and can be fixed.
>> 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?
> Yup. I thought about this a little. The problem is the security related
> stuff (trusted ports/network) needs to be done at a very low level (BMI)
> while the file-system level export options need to be done at a fairly
> high level. Also, I think the security options were more of a global
> decision than a per-filesystem one.
I agree with you that this stuff tends to be applied at different
places. I'm not sure that we intended the existing security options to
be global -- we didn't really discuss it. I think both of these things
are really intended to be per file system, even if we don't really
support that level of granularity yet.
> Right now, there are not too many interfaces to facilitate
> passing information between the two layers. So for instance, at the time
> the connect is accepted or rejected, do we have the server_req structure yet?
> We still havent done the receive on them, right?
> If we were to move the security stuff to the higher levels then we would
> have to accept the connection and somehow close the connection if the f.s
> export checks don't come thru. How do either of these approaches sound to
We've got a working system for dealing with TCP connections, and I think
we should just stick with that mechanism.
Likewise, applying these other uid/gid manipulations in the prelude as
you do in the patch makes equally good sense. Maybe you could do the
setattr-related changes at the same time in prelude (if needed at all),
to keep all that code in one place? Just an idea.
It does get more complicated if we want to be able to apply root squash
only for a specific set of clients, for example. I don't want to try to
figure that one out right now though; we got more performance to chase
More information about the PVFS2-developers