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