On Fri, 28 Jun 2013 10:25:52 -0500 Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote: > Quoting Dave Chinner (david@xxxxxxxxxxxxx): > > On Thu, Jun 27, 2013 at 08:02:05AM -0500, Serge Hallyn wrote: > > > Quoting Dave Chinner (david@xxxxxxxxxxxxx): > > > > On Wed, Jun 26, 2013 at 05:30:17PM -0400, Dwight Engen wrote: > > > > > On Wed, 26 Jun 2013 12:09:24 +1000 > > > > > Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > > > > We do need to decide on the di_uid that comes back from > > > > > > > bulkstat. Right now it is returning on disk (== > > > > > > > init_user_ns) uids. It looks to me like xfsrestore is > > > > > > > using the normal vfs routines (chown, > > > > > > I might not be helpful here, (as despite having used xfs for years > > > I've not used these features) but feel like I should try based on > > > what I see in the manpages. Here is my understanding: > > > > > > Assume you're a task in a child userns, where you have host uids > > > 100000-110000 mapped to container uids 0-10000, > > > > > > 1. bulkstat is an xfs_ioctl command, right? It should return the > > > mapped uids (0-10000). > > > > > > 2. xfsdump should store the uids as seen in the caller's > > > namespace. If xfsdump is done from the container, the dump > > > should show uids 0-10000. > > > > So when run from within a namespace, it should filter and return > > only inodes that match the uids/gids mapped into the namespace? > > I would think they should all be returned, with uid/gid being -1. I agree, so I think bulkstat should return the uids with from_kuid_munged(current_user_ns(), VFS_I(ip)), so it returns the same values that stat(2) would. This would mean callers in init_user_ns see the same values they do today. Callers inside a userns will see mapped values, but note that they have to be CAP_SYS_ADMIN in init_user_ns, which I wouldn't expect to normally be the case. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
