public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dwight Engen <dwight.engen@oracle.com>
To: xfs@oss.sgi.com, Dave Chinner <david@fromorbit.com>,
	Brian Foster <bfoster@redhat.com>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>,
	"Eric W. Biederman" <ebiederm@gmail.com>
Subject: [PATCH v6 0/7] userns: Convert xfs to use kuid_t/kgid_t where appropriate
Date: Thu, 25 Jul 2013 11:49:15 -0400	[thread overview]
Message-ID: <20130725114915.6cda13c6@oracle.com> (raw)

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.

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

                 reply	other threads:[~2013-07-25 15:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20130725114915.6cda13c6@oracle.com \
    --to=dwight.engen@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.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