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.
Ok.
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
you?
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
after first.
Thanks,
Rob
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
