[Lustre-devel] Moving forward on Quotas

[Peter Braam]

I did not read the entire long message, but clearly the importance of
authorizing operations on the OSS far exceeds that of exposing a uid to a
client.

Moreover, it doesn't have to be exposed.  If the capability contains the uid
it can be encrypted with a key so that only the OSS can see it.

This seems the preferred solution.

Peter


On 6/10/08 7:54 AM, "Yong Fan" <Yong.Fan at Sun.COM> wrote:

> Peter Braam 写道:
>> 
>> On 6/6/08 1:33 AM, "Johann Lombardi" <johann at sun.com> wrote:
>> 
>>   
>>> On Thu, Jun 05, 2008 at 06:45:36AM -0700, Peter Braam wrote:
>>>     
>>>> Well, this protocol hasn't been published yet; why not include the server
>>>> side uid / gid then?
>>>>       
>>> I understood from Fanyong that according to the remote client design
>>> requirements, we should not allow the remote client to access the
>>> server-side
>>> uid/gid mapping.
>>>     
>> 
>> You have two choices: break that rule OR let the MDS server do the ownership
>> changes.  It's not complicated, just make a choice.
>>   
> 1) MDS changes file owner for objects on OSS when create.
> It introduces one additional RPC between MDS and OSS
> for each objects, which causes the per-create meaningless.
> Maybe we can not accept the creation performance undre
> such case.
> An improvement for that is that we can initialize all
> the pre-create objects on OSS with the same uid/gid as
> the current created file. And the succedent creations
> check the per-created object's uid/gid, if they match
> the owner's uid/gid, then the additional setattr to OSS
> is unnecessary, otherwise, chown to OSS will be sent.
> The best case is equal to the current implementation;
> the worst case is equal to no such improvement.
> Under creation performance sensitivity case, maybe HPC
> or some benchmark test. There are few uid/gid context
> switch. So I think such improvement can match most
> creation performance requirement.
> 2) Pack file owner into OSS capability when write to OSS.
> According to our UID mapping rules, we do not want the
> client (especially the untrusted client, maybe remote
> client) to know which the server-side uid/gid are mapped.
> For that, dynamic UID mapping are used, and some complex
> remote acl operations are implemented.
> So if file real owner (server-side uid/gid) need to be
> packed in OSS capability back to client, bad better to
> encrypt them to match our UID mapping rules. Otherwise,
> most of our effort for that before are broken. On the
> other hand, MDS/OSS capabilities use HMAC-SHA1 to prevent
> from being modified or fabricated. Signing MAC is somewhat
> time-consuming, and uid/gid encryption are similar, so the
> performance will become worse. To implement server-side
> uid/gid encryption and decryption, need to design some
> key-update mechanism also.
> So I do not think it is a good choice.
> 3) Establish UID mapping on OSS also, just like MDS does.
> It has the same principle as done on MDS which needs
> lower layer GSS support. Many codes can be shared
> between MDS and OSS for UID mapping. It is the most
> complete solution, little affect on creation performance
> and UID mapping rules. The shortcoming is much changes
> on OSS, how much GSS effort for that is not well estimated
> yet.
>>   
>>>> But more seriously, how is this encoded in such a way that the OST can
>>>> trust
>>>> the information - it must be in the capability too?
>>>>       
>>> hmm, I don't see any capability associated with this.
>>>     
>> 
>> We had better find it, otherwise there is a security hole.
>> 
>>   
> Root user's super permission should be considered for OSS
> capability. On client-side, the opened file descriptor can
> be shared by different threads, and the different threads
> maybe have different "uid". Consider the following case:
> Root user writes a file through other normal user (Tom)
> opened file descriptor. The root user can breaks through
> Tom's quota limitation, he should tell OSS that he is a
> root user, but how can the OSS believe him? Such information
> should be contained in the OSS capability.
> (Note: on lustre 1.6, llite set "OBD_BRW_NOQUOTA" directly
> for that, which can be fabricated by baleful client)
> 
> Best Regards!
> --
> Fan Yong
>>   
>>> Johann
>>> _______________________________________________
>>> Lustre-devel mailing list
>>> Lustre-devel at lists.lustre.org
>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>>     
>> 
>> 
>>   
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel