[Lustre-devel] Security issues

Vitaly Fertman vitaly at sun.com
Mon Aug 11 05:56:14 PDT 2008

On Aug 8, 2008, at 9:12 PM, Peter Braam wrote:
>> 2. Securing Capabilities.
>> If we want to be sure that a Capability given to client A cannot be
>> snooped and used by client B we either (a) have to make the  
>> Capability
>> secret (i.e. never passed in cleartext) or (b) have to make the  
>> Capability
>> identify which client it is valid for.
>> It seems to me that (b) is preferrable since it ensures that a  
>> malicious
>> client cannot leak Capabilities to a 3rd party.  The downside is  
>> that this
>> multiplies the number of unique Capabilities by the number of  
>> clients,
>> potentially increasing CPU load when 1000s of clients all open the  
>> same
>> shared file and each require unique Capabilities to access the  
>> stripe objects.
>> Do we have a feel for how bad this could be?
> Yes, very bad, and it is absolutely necessary to have an option that  
> avoids this (also 1000s is out of date – it could be 100x worse).   
> That option could be to simply not have security on the compute  
> cluster if customers agree with this.

this kind of problem also exists for OST capabilities even without  
them unique per client.

As objects do not know the mds fid initially, we can check the  
operation is
intended for this particular object by objid/gr only. The proposed  
solution was
to generate on mds an objid-based capa for each object instead of 1  
fid-based capa (i.e. a pair objid/group is signed instead of mds fid),  
therefore we give out default-stripe-count OST capas instead of 1  
every time.

it could be optimized later, by switching to fid-based capas with time  
mds gets known all the objects know the mds fid. however, the mechanism
is not clear yet.


More information about the lustre-devel mailing list