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... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
