From: Dave Chinner <david@fromorbit.com>
To: Gao feng <gaofeng@cn.fujitsu.com>
Cc: bfoster@redhat.com, dwight.engen@oracle.com,
ebiederm@xmission.com, xfs@oss.sgi.com
Subject: Re: [PATCH 0/4] xfs: Allow user to change project id in un-init userns
Date: Tue, 10 Sep 2013 10:42:10 +1000 [thread overview]
Message-ID: <20130910004210.GX12779@dastard> (raw)
In-Reply-To: <20130906013033.GB23571@dastard>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-10 0:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-04 6:38 [PATCH 0/4] xfs: Allow user to change project id in un-init userns Gao feng
2013-09-04 6:38 ` [PATCH 1/4] xfs: add helper function to convert project id between user and kernel space Gao feng
2013-09-04 6:38 ` [PATCH 2/4] userns: ioctl: " Gao feng
2013-09-04 6:38 ` [PATCH 3/4] xfs: allow un-init user namespace to change file's project id Gao feng
2013-09-04 6:38 ` [PATCH 4/4] userns: eofblocks: convert project id from user to kernel space Gao feng
2013-09-06 1:30 ` [PATCH 0/4] xfs: Allow user to change project id in un-init userns Dave Chinner
2013-09-10 0:42 ` Dave Chinner [this message]
2013-09-10 1:20 ` Gao feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130910004210.GX12779@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=dwight.engen@oracle.com \
--cc=ebiederm@xmission.com \
--cc=gaofeng@cn.fujitsu.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.