Nicolas Williams wrote:
On Tue, Mar 31, 2009 at 02:37:02PM -0500, Mike Gerdts wrote:
The <user> or <group> is specified using one of the following forms:
posix name (eg. ahrens)
posix numeric id (eg. 126829)
sid name (eg. ahr...@sun)
sid numeric id (eg. S-1-12345-12423-125829)
How does this work with zones? Suppose in the global zone I have
passwd entries like:
ZFS stores UIDs, GIDs and SIDs on disk. The POSIX ID/SID <-> name
resolution happens in user-land. As such the answer to your question is
the same as for any other operating system facility that deals with
POSIX ID/SID <-> name resolution: it depends on each zone's
configuration.
Right, so you'll get the same answer as if you did a "ls" on those files (if
the local zone's files were available to the global zone).
(In general kernel code never deals with user/group names directly, but
with UIDs/GIDs/SIDs. One exception is the NFSv4 code, which upcalls to
user-land to resolve NFSv4 n...@domain user/group names and vice versa.)
>
jill:x:123:123:Jill Admin:/home/jill:/bin/bash
joe:x:124:124:Joe Admin:/home/joe:/bin/bash
And in a non-global zone (called bedrock) I have:
fred:x:123:123:Fred Flintstone:/home/fred:/bin/bash
barney:x:124:124:Barney Rubble:/home/barney:/bin/bash
Dataset rpool/quarry is delegated to the zone bedrock.
Does "zfs get all rpool/quarry" report the same thing whether it is
run in the global zone or the non-global zone?
If you use the -n option, yes :)
Oh, but then, the -n option is for the new zfs {user|group}space
sub-command. I don't think "zfs get" is getting that option; maybe it
should.
Since "zfs get all" doesn't report the {user|group}{used|quo...@...
properties, you will definitely get the same answer ;-)
<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.
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.
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
