I would like to make a couple of additions to the proposed model.
----
Permission Sets.
Allow the administrator to define a named set of permissions, and then
use the name as a permission later on. Permission sets would be
evaluated dynamically, so that changing the set definition would change
what is allowed everywhere the set is used.
Permission sets would need a special character to differentiate it from
a normal permission. I would like to recommend we use the '@' character
for this.
The -s option will be used to manipulate a named set.
# zfs allow -s @<setname> <perm>,<perm>... <dataset>
# zfs unallow -s @<setname> <perm>,<perms>... <dataset>
# zfs unallow -s @<setname> <dataset>
Set Examples:
First we need to define the set (@myset)
# zfs allow -s @myset create,destroy,snapshot,clone datapool
Now let group staff use the named set (@myset).
# zfs allow staff @myset datapool
You could also mix a named set with a normal permission list
# zfs allow fred @myset,mount,promote datapool/fred
When a permission set is evaluated the nearest ancestor that defines the
named set would be used.
Permission printing.
With permission sets displaying the various permissions becomes a little
messy. I would like to propose the following format. Its a bit
verbose, but it is readable.
--------------------------------------------------------------------------
Permission sets on (pool/fred)
@set1 create,destroy,snapshot,mount,clone,promote,rename
@simple create,mount
Create time permissions on (pool/fred)
@set1,mountpoint
Local permissions on (pool/fred)
user tom @set1
user joe create,destroy,mount
Local+Descendent permissions on (pool/fred)
user fred @basic,share,rename
Descendent permissions on (pool/fred)
user barney @basic
group staff @basic
--------------------------------------------------------------------------
Permission sets on (pool)
@simple create,destroy,mount
Local permissions on (pool)
group staff @simple
--------------------------------------------------------------------------
Mark Shellenbaum 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
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
