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

[Sam Lang]

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