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.
James Dickens
uadmin.blogspot.com
PERMISSION REVOKING
zfs unallow <dataset> [-r] [-l] [-d]
<"everyone"|user|group>[,<"everyone"|user|group>...] \
<ability>[,<ability>...] <dataset>
zfs unallow [-r][-l][-d] -u user <ability>[,<ability>...] <dataset>
zfs unallow [-r][-l][-d] -g group <ability>[,<ability>...] <dataset>
zfs unallow [-r][-l][-d] -e <ability>[,<ability>...] <dataset>
'zfs unallow' removes permissions that were granted with 'zfs allow'.
Note that this does not explicitly deny any permissions; the permissions
may still be allowed by ancestors of the specified dataset.
-l "Local" will cause only the Local permission to be removed.
-d "Descendents" will cause only the Descendant permissions to be
removed.
-r "Recursive" will remove the specified permissions from all descendant
datasets, as if 'zfs unallow' had been run on each descendant.
Note that '-r' removes abilities that have been explicitly set on
descendants, whereas '-d' removes abilities that have been set on *this*
dataset but apply to descendants.
PERMISSION PRINTING
zfs allow [-1] <dataset>
prints permissions that are set or allowed on this dataset, in the
following format:
<whotype> <who> <ability>[,<ability>...] (<type>)
<whotype> is "user", "group", or "everyone"
<who> is the user or group name, or blank for everyone and create
<type> can be:
"Local" (ie. set here with -l)
"Descendent" (ie. set here with -d)
"Local+Descendent" (ie. set here with no flags)
"Create" (ie. set here with -c)
"Inherited from <dataset>" (ie. set on an ancestor without -l)
By default, only one line with a given <whotype>,<who>,<type> will be
printed (ie. abilities will be consolodated into one line of output
where possible).
-1 "One" will cause each line of output to print only a single ability,
and a single type (ie. not use "Local+Descendent")
ALLOW EXAMPLE
Lets setup a public build machine where engineers in group "staff" can create
ZFS file systems,clones,snapshots and so on, but you want to allow only
creator of the file system to destroy it.
# zpool create sandbox <disks>
# chmod 1777 /sandbox
# zfs allow -l staff create
# zfs allow -c create,destroy,snapshot,clone,promote,mount sandbox
$ zfs create sandbox/marks
Now verify that a different user can't destroy it
% zfs destroy sandbox/marks
cannot destroy 'sandbox/marks': permission denied
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
