On Dec 8, 2005, at 1:16 PM, Sam Lang wrote:
On Dec 8, 2005, at 12:31 PM, Murali Vilayannur wrote:
Hi Rob,
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?
Hmm. Let me find out what nfs semantics are and replicate the
behavior.
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.
Yup. I agree with you that they are meant to be per-file-system. I
just
could not figure out a clean way to get to the f.s stuff from the BMI
layer. So it turned out to be a global option. :(
One way to do this might be to pass in the filesystem_config
pointer cur_fs instead of the server_config pointer to the
BMI_set_info(... BMI_TRUSTED_CONNECTION ...) call. That will at
least let you call get_allowed_ports on the fs_config instead. To
get the filesystem_config, you just need the fsid
(PINT_config_find_fs_id), and you should have it at the level from
which BMI_set_info is called. If you still need to go back and get
global security config options
....there should be a way to do this from the filesystem
config...although I don't see an obvious way at present...
As a side note, if we're going to be changing that stuff anyway,
does it make sense to move the trusted ports/networks stuff one
layer up to the BMI layer? I feel like putting it just in bmi_tcp
is wrong, esp. since there's nothing in the Security config options
that specifies which bmi module to use. It seems like either we
should add a required option to the Security context that specifies
which bmi modules these apply to (and its always just tcp for now),
other the bmi modules should support the trusted ports/networks stuff.
-sam
We've got a working system for dealing with TCP connections, and
I think
we should just stick with that mechanism.
Could you elaborate on this one? I dont think I understand that layer
completely yet.
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.
okay, that makes sense! I can get that done.
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.
Yup. I agree.
Thanks,
Murali
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
