public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Gao feng <gaofeng@cn.fujitsu.com>
To: Dwight Engen <dwight.engen@oracle.com>
Cc: "Eric W. Biederman" <ebiederm@gmail.com>,
	Brian Foster <bfoster@redhat.com>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	xfs@oss.sgi.com
Subject: Re: [PATCH v7 0/7] userns: Convert xfs to use kuid_t/kgid_t where appropriate
Date: Wed, 31 Jul 2013 14:30:38 +0800	[thread overview]
Message-ID: <51F8AF0E.3020409@cn.fujitsu.com> (raw)
In-Reply-To: <20130729230633.725a282e@oracle.com>

Hi Dwight,

On 07/30/2013 11:06 AM, Dwight Engen wrote:
> Hi All,
> 
> This updated patchset is on top of ad81f054 of xfs git (3.11-rc1). The
> patches do not convert the id's returned from bulkstat, since bulkstat
> cannot be called from inside a userns right now anyway since the caller
> must be CAP_SYS_ADMIN in init_user_ns.


As I method in another mail thread, I found the changing projid of file in container
hasn't been disallowed. it means the user in container can change file's projid.
so the project quota won't take effect.

the project quota info before I change file's projid in container:

Project quota on /media/lw (/dev/sdc1)
                        Blocks
Project ID   Used   Soft   Hard Warn/Grace
---------- ---------------------------------
testproj      64K   100M   110M  00 [------]


and after I use a simple program which execs the below code.

fa.fsx_projid = 21; // different projid from testproj
fa.fsx_xflags &= ~XFS_XFLAG_IMMUTABLE;
ret = xfsctl("/mount_point_of_xfs", fd, XFS_IOC_FSSETXATTR, &fa);

the project quota becomes to:

Project quota on /media/lw (/dev/sdc1)
                        Blocks
Project ID   Used   Soft   Hard Warn/Grace
---------- ---------------------------------
testproj      60K   100M   110M  00 [------]


So I think we still need a patch to reduce the changing-project-id
rights of un-init user namespace.

Thanks


> 
> Changes since v6 patchset (addressing Dave's comments)
> - 0006 just do a capable(CAP_SYS_ADMIN) check for XFS_IOC_FREE_EOFBLOCKS
> 
> Changes since v5 patchset (addressing Brian's comments,
> only 0005 and 0006 are changed):
>  - 0005 put all eofblocks validation in xfs_fs_eofblocks_from_user()
>  - 0006 don't export internal flag, add K to internal flag name,
>    start internal flags bits at msb (with the intention that other internal
>    flags would be in descending order) and ensure that it doesn't accidentally
>    collide with external flags
> 
> Changes since v4 patchset (addressing Dave's comments):
>  - add parenthesis in if with binary and logical and (EOFBLOCKS flags)
>  - rename xfs_fs_eofblocks_to_internal -> xfs_fs_eofblocks_from_user and
>    move conversion validation into it
>  - fix negative error returns from XFS_IOC_FREE_EOFBLOCKS
>  - add check for read-only filesystem to XFS_IOC_FREE_EOFBLOCKS
> 
> Changes since v3 patchset:
>  - export inode_capable() for building xfs as a module
>  - implement Brian's proposal for an internal flag to indicate to
>    xfs_inode_free_eofblocks() that it should do a permission check.
>    ioctl callers will always set this flag, which is simpler than
>    making them specify XFS_EOF_FLAGS_UID or XFS_EOF_FLAGS_GID,
>    internal callers can leave it unset so no permission checking is
>    done
>  - take Brian's suggestion on moving the policy from the conversion
>    function into the ioctl code, and moving stuff to xfs_icache.h
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

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

      reply	other threads:[~2013-07-31  6:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-30  3:06 [PATCH v7 0/7] userns: Convert xfs to use kuid_t/kgid_t where appropriate Dwight Engen
2013-07-31  6:30 ` Gao feng [this message]

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=51F8AF0E.3020409@cn.fujitsu.com \
    --to=gaofeng@cn.fujitsu.com \
    --cc=bfoster@redhat.com \
    --cc=dwight.engen@oracle.com \
    --cc=ebiederm@gmail.com \
    --cc=serge.hallyn@ubuntu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox