xfs
[Top] [All Lists]

Re: [PATCH 0/4] xfs: Allow user to change project id in un-init userns

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 0/4] xfs: Allow user to change project id in un-init userns
From: Gao feng <gaofeng@xxxxxxxxxxxxxx>
Date: Tue, 10 Sep 2013 09:20:20 +0800
Cc: bfoster@xxxxxxxxxx, dwight.engen@xxxxxxxxxx, ebiederm@xxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130910004210.GX12779@dastard>
References: <1378276717-9663-1-git-send-email-gaofeng@xxxxxxxxxxxxxx> <20130906013033.GB23571@dastard> <20130910004210.GX12779@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
On 09/10/2013 08:42 AM, Dave Chinner wrote:
> On Fri, Sep 06, 2013 at 11:30:33AM +1000, Dave Chinner wrote:
>> On Wed, Sep 04, 2013 at 02:38:33PM +0800, Gao feng wrote:
>>> This patchset add two helper functions to convert user space project id
>>> to kernel space project id without any struct changed.
>>>
>>> Since the projid_map of user namespace has limit the range of valid project
>>> ids for user namespace, we can safely allow user to change file's project
>>> id in un-init user namespace.
>>
>> This doesn't address any of the concerns about whether access to
>> project IDs are valid in a user namaspacee environment.
>>
>> Project IDs are not the same as UIDs and GIDs. They got included in
>> all the mapping stuff because of the fact that they are used for
>> quotas, but the fact is that they are not a property owned by a user
>> or a group or control access.
>>
>> IOWs, project IDs are an *accounting* construct rather than an
>> *access control mechanism* If project IDs are being used by the
>> system administrators for accounting the space used by a *mount
>> namespace* container, then they must not be modifiable by a user
>> in a user namespace.
>>
>> This is a fundamentally different use case from UID/GID mapping,
>> because there is no possible competing access for on-disk uid/gid
>> fields possible from the initns like there is for project quotas.
>> IOWs, project quota IDs are not owned by a namespace, and so mapping
>> them like we do for UID/GID is not clearly the right solution for
>> everyone.
>>
>> So, there's a bigger policy issue here that needs to be decided
>> first. i.e. whether project quotas and therefore project IDs should
>> be accessible to users inside a user namespace.
>>
>> If we decide to make it optional so that a system administrator can
>> chose whether project IDs are to be mapped via the userns mapping
>> infrastructure, then we need some kind of infrastructure to support
>> and enforce that first.
> 
> BTW, if we are making project IDs mapped to userns, stuff like
> XFS_PROJID_DEFAULT and project ID inheritence need work as well...
> 


Yes, let's make it simple, if we find some cases that we have to make
project IDs mapped to userns, let's restart this work :)

Thanks

<Prev in Thread] Current Thread [Next in Thread>