[PVFS2-developers] Re: Limit a particular pvfs2 client's access
slang at mcs.anl.gov
Thu Dec 8 13:16:00 EST 2005
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
>> 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
>> 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
> 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
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.
>> We've got a working system for dealing with TCP connections, and I
>> 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
>> 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
>> 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
>> after first.
> Yup. I agree.
> PVFS2-developers mailing list
> PVFS2-developers at beowulf-underground.org
More information about the PVFS2-developers