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

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs