On Tue, Mar 31, 2009 at 01:25:35PM -0700, Matthew Ahrens wrote: > <quote case materials> > These new properties are not printed by "zfs get all", since that could > generate a huge amount of output, which would not be very well > organized. The new "zfs userspace" subcommand should be used instead.
Ah, I missed that. > >>Has there been any thought to using a UID resolution mechanism similar > >>to that used by ps? That is, if "zfs get ... <dataset>" is run in the > >>global zone and the dataset is deleted to a non-global zone, display > >>the UID rather than a possibly mistaken username. > > > >That seems like a good idea to me. You should send that comment to the > >ARC case record (send an e-mail to psarc-...@sun.com with > >"PSARC/2009/204" somewhere in the Subject: header). > > Indeed, that might be a good idea. I wasn't aware of that convention. > Though note that this only applies to "zfs userspace" -- we would simply > say that if the fs is zoned, that implies the -n option. We could also > disallow them from doing "zfs get useru...@name pool/zoned/fs", just make > it an error to prevent them from seeing something other than what they > intended. I don't see why the g-z admin should not get this data. Having to zlogin to get it seems wrong to me. Though, obviously, you'd have to zlogin to get zone-local _names_ -- one might want extended getXbyYs to do ID->zone-local name resolution in the g-z, though one then worries about ngz admins attacking the g-z admin through user/group names that are not properly encoded for the g-z admin's locale... (so we're likely to never do this). Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
