James Dickens wrote:
On 7/17/06, Mark Shellenbaum <[EMAIL PROTECTED]> wrote:
The following is the delegated admin model that Matt and I have been
working on. At this point we are ready for your feedback on the
proposed model.
-Mark
PERMISSION GRANTING
zfs allow [-l] [-d] <"everyone"|user|group>
<ability>[,<ability>...] \
<dataset>
zfs allow [-l] [-d] -u <user> <ability>[,<ability>...] <dataset>
zfs allow [-l] [-d] -g <group> <ability>[,<ability>...] <dataset>
zfs allow [-l] [-d] -e <ability>[,<ability>...] <dataset>
zfs allow -c <ability>[,<ability>...] <dataset>
If no flags are used, the ability will be allowed for the specified
dataset and all of its descendents.
-l "Local" means that the permission will be allowed for the
specified dataset, and not its descendents (unless -d is also
specified).
-d "Descendents" means that the permission will be allowed for
descendent datasets, and not for this dataset (unless -l is also
specified). (needed for 'zfs allow -d ahrens quota tank/home/ahrens')
When using the first form (without -u, -g, or -e), the
<"everyone"|user|group> argument will be interpreted as the keyword
"everyone" if possible, then as a user if possible, then as a group as
possible. The "-u <user>", "-g <group>", and "-e (everyone)" forms
allow one to specify a user named "everyone", or a group whose name
conflicts with a user (or "everyone"). (note: the -e form is not
necessary since "zfs allow everyone" will always mean the keyword
everyone not the user everyone.)
As a possible extension, multiple <who>'s could be allowed in one
command (eg. 'zfs allow -u ahrens,marks create tank/project')
-c "Create" means that the permission will be granted (Locally) to the
creator on any newly-created descendant filesystems.
Abilities are mostly self explanatory, the ability to run
'zfs [set] <ability> <ds>'. Note, this implicitly collapses the
subcommand and property namespaces into one. (I think that the 'set' is
superfluous anyway, it would be more convenient to say
'zfs <property>=<value>' anyway.)
create create descendent datasets
destroy
snapshot
rollback
clone create clone of any of the ds's snaps
(must also have 'create' ability in clone's
parent)
promote (must also have 'promote' ability in origin fs)
rename (must also have 'create' ability in new parent)
mount mount and unmount the ds
share share and unshare this ds
send send any of the ds's snapshots
receive create a descendent with 'zfs receive'
(must also have 'create' ability)
quota
reservation
volsize
recordsize
mountpoint
sharenfs
checksum
compression
atime
devices
exec
setuid
readonly
zoned
snapdir
aclmode
aclinherit
Hi
just one addition, "all" or "full" attributes, for the case you want
to get full permissions to the user or group
zfs create p1/john
zfs allow p1/john john full
so we don't have to type out every attribute.
I think you wanted
zfs allow john full p1/john
We could have either a "full" or "all" to represent all permissions, but
the problem with that is that you will then end up granting more
permissions than are necessary to achieve the desired goal.
If enough people think its useful then we can do it.
James Dickens
uadmin.blogspot.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
