[PVFS2-developers] Re: Limit a particular pvfs2 client's access to data

[Sam Lang]

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

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
> PVFS2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>