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.Overall this looks really good. I might have some detailed comments after a third reading, but I think it certainly covers functionality I need. -- Darren J Moffat
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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delegation URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060717/b0603db0/attachment.ksh>
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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discussSo as administrator what do I need to do to set /export/home up for users to be able to create their own snapshots, create dependent filesystems (but still mounted underneath their /export/home/usrname)? In other words, is there a way to specify the rights of the owner of a filesystem rather than the individual - eg, delayed evaluation of the owner? - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
On Mon, Jul 17, 2006 at 09:44:28AM -0700, Bart Smaalders wrote:> Mark Shellenbaum wrote: > >PERMISSION GRANTING > > > > zfs allow -c <ability>[,<ability>...] <dataset> > > > >-c "Create" means that the permission will be granted (Locally) to the > >creator on any newly-created descendant filesystems. > > > >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 sandbox > ># zfs allow -c create,destroy,snapshot,clone,promote,mount sandbox > > So as administrator what do I need to do to set > /export/home up for users to be able to create their own > snapshots, create dependent filesystems (but still mounted > underneath their /export/home/usrname)? > > In other words, is there a way to specify the rights of the > owner of a filesystem rather than the individual - eg, delayed > evaluation of the owner?I think you''re asking for the -c "Creator" flag. This allows permissions (eg, to take snapshots) to be granted to whoever creates the filesystem. The above example shows how this might be done. --matt
Matthew Ahrens wrote:> On Mon, Jul 17, 2006 at 09:44:28AM -0700, Bart Smaalders wrote: >> Mark Shellenbaum wrote: >>> PERMISSION GRANTING >>> >>> zfs allow -c <ability>[,<ability>...] <dataset> >>> >>> -c "Create" means that the permission will be granted (Locally) to the >>> creator on any newly-created descendant filesystems. >>> >>> 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 sandbox >>> # zfs allow -c create,destroy,snapshot,clone,promote,mount sandbox >> So as administrator what do I need to do to set >> /export/home up for users to be able to create their own >> snapshots, create dependent filesystems (but still mounted >> underneath their /export/home/usrname)? >> >> In other words, is there a way to specify the rights of the >> owner of a filesystem rather than the individual - eg, delayed >> evaluation of the owner? > > I think you''re asking for the -c "Creator" flag. This allows > permissions (eg, to take snapshots) to be granted to whoever creates the > filesystem. The above example shows how this might be done. > > --mattActually, I think I mean owner. I want root to create a new filesystem for a new user under the /export/home filesystem, but then have that user get the right privs via inheritance rather than requiring root to run a set of zfs commands. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
On Mon, Jul 17, 2006 at 10:00:44AM -0700, Bart Smaalders wrote:> >>So as administrator what do I need to do to set > >>/export/home up for users to be able to create their own > >>snapshots, create dependent filesystems (but still mounted > >>underneath their /export/home/usrname)? > >> > >>In other words, is there a way to specify the rights of the > >>owner of a filesystem rather than the individual - eg, delayed > >>evaluation of the owner? > > > >I think you''re asking for the -c "Creator" flag. This allows > >permissions (eg, to take snapshots) to be granted to whoever creates the > >filesystem. The above example shows how this might be done. > > > >--matt > > Actually, I think I mean owner. > > I want root to create a new filesystem for a new user under > the /export/home filesystem, but then have that user get the > right privs via inheritance rather than requiring root to run > a set of zfs commands.In that case, how should the system determine who the "owner" is? We toyed with the idea of figuring out the user based on the last component of the filesystem name, but that seemed too tricky, at least for the first version. FYI, here is how you can do it with an additional zfs command: # zfs create tank/home/barts # zfs allow barts create,snapshot,... tank/home/barts --matt
Bart Smaalders wrote:> Matthew Ahrens wrote: >> On Mon, Jul 17, 2006 at 09:44:28AM -0700, Bart Smaalders wrote: >>> Mark Shellenbaum wrote: >>>> PERMISSION GRANTING >>>> >>>> zfs allow -c <ability>[,<ability>...] <dataset> >>>> >>>> -c "Create" means that the permission will be granted (Locally) to the >>>> creator on any newly-created descendant filesystems. >>>> >>>> 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 sandbox >>>> # zfs allow -c create,destroy,snapshot,clone,promote,mount sandbox >>> So as administrator what do I need to do to set >>> /export/home up for users to be able to create their own >>> snapshots, create dependent filesystems (but still mounted >>> underneath their /export/home/usrname)? >>> >>> In other words, is there a way to specify the rights of the >>> owner of a filesystem rather than the individual - eg, delayed >>> evaluation of the owner? >> >> I think you''re asking for the -c "Creator" flag. This allows >> permissions (eg, to take snapshots) to be granted to whoever creates the >> filesystem. The above example shows how this might be done. >> >> --matt > > Actually, I think I mean owner. > > I want root to create a new filesystem for a new user under > the /export/home filesystem, but then have that user get the > right privs via inheritance rather than requiring root to run > a set of zfs commands. >Yes, you can delegate snapshot,clone,... # zfs allow <user> snapshot,mount,clone,<whatever> pool that will allow the above permissions to be inherited by all datasets in the pool. If you wanted to open it up even more you could do # zfs allow everyone snapshot,mount,clone,<whatever> pool That would allow anybody to create a snapshot,clone,... The -l and -d control the inheritance of the allow permissions.> - Bart >
Matthew Ahrens wrote:> On Mon, Jul 17, 2006 at 10:00:44AM -0700, Bart Smaalders wrote: >>>> So as administrator what do I need to do to set >>>> /export/home up for users to be able to create their own >>>> snapshots, create dependent filesystems (but still mounted >>>> underneath their /export/home/usrname)? >>>> >>>> In other words, is there a way to specify the rights of the >>>> owner of a filesystem rather than the individual - eg, delayed >>>> evaluation of the owner? >>> I think you''re asking for the -c "Creator" flag. This allows >>> permissions (eg, to take snapshots) to be granted to whoever creates the >>> filesystem. The above example shows how this might be done. >>> >>> --matt >> Actually, I think I mean owner. >> >> I want root to create a new filesystem for a new user under >> the /export/home filesystem, but then have that user get the >> right privs via inheritance rather than requiring root to run >> a set of zfs commands. > > In that case, how should the system determine who the "owner" is? We > toyed with the idea of figuring out the user based on the last component > of the filesystem name, but that seemed too tricky, at least for the > first version. > > FYI, here is how you can do it with an additional zfs command: > > # zfs create tank/home/barts > # zfs allow barts create,snapshot,... tank/home/barts > > --mattOwner of the top level directory is the owner of the filesystem? - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
Bart Smaalders wrote:> Matthew Ahrens wrote: >> On Mon, Jul 17, 2006 at 10:00:44AM -0700, Bart Smaalders wrote: >>>>> So as administrator what do I need to do to set >>>>> /export/home up for users to be able to create their own >>>>> snapshots, create dependent filesystems (but still mounted >>>>> underneath their /export/home/usrname)? >>>>> >>>>> In other words, is there a way to specify the rights of the >>>>> owner of a filesystem rather than the individual - eg, delayed >>>>> evaluation of the owner? >>>> I think you''re asking for the -c "Creator" flag. This allows >>>> permissions (eg, to take snapshots) to be granted to whoever creates >>>> the >>>> filesystem. The above example shows how this might be done. >>>> >>>> --matt >>> Actually, I think I mean owner. >>> >>> I want root to create a new filesystem for a new user under >>> the /export/home filesystem, but then have that user get the >>> right privs via inheritance rather than requiring root to run >>> a set of zfs commands. >> >> In that case, how should the system determine who the "owner" is? We >> toyed with the idea of figuring out the user based on the last component >> of the filesystem name, but that seemed too tricky, at least for the >> first version. >> >> FYI, here is how you can do it with an additional zfs command: >> >> # zfs create tank/home/barts >> # zfs allow barts create,snapshot,... tank/home/barts >> >> --matt > > Owner of the top level directory is the owner of the filesystem? >When a file system is created the owner/group of the root of the file system are set to the user/group of the user executing the zfs create command. That is also the user that all of the initial create time permissions are set to. -Mark
On Mon, Jul 17, 2006 at 10:11:35AM -0700, Matthew Ahrens wrote:> > I want root to create a new filesystem for a new user under > > the /export/home filesystem, but then have that user get the > > right privs via inheritance rather than requiring root to run > > a set of zfs commands. > > In that case, how should the system determine who the "owner" is? We > toyed with the idea of figuring out the user based on the last component > of the filesystem name, but that seemed too tricky, at least for the > first version.The owner of the root directory of the ZFS filesystem in question. Could delegation be derived from the ACL of the directory that would contain a new ZFS filesystem? E.g., # zfs create pool/foo # chown joe pool/foo # su - joe % zfs create pool/foo/a % chmod <add ACE that allows jane to create directories> /pool/foo/a % exit # su - jane % zfs create pool/foo/a/b % ... After all, with cheap filesystems creating a filesystem is almost like creating a directory (I know, not quite the same, but perhaps close enough for reusing the add_subdirectory ACE flag). Nico --
On 7/17/06, Mark Shellenbaum <Mark.Shellenbaum at sun.com> 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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > >
Glenn Skinner wrote:> The following is a nit-level comment, so I''ve directed it onl;y to you, > rather than to the entire list. > > Date: Mon, 17 Jul 2006 09:57:35 -0600 > From: Mark Shellenbaum <Mark.Shellenbaum at sun.com> > Subject: [zfs-discuss] Proposal: delegated administration > > 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. > > ... > 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> > > Please, can we have "disallow" instead of "unallow"? The former is a > real word, the latter isn''t. > > -- Glenn >The reasoning behind unallow was to imply that you are simply removing an "allow". With *disallow* it would sound more like you are denying a permission. -Mark
James Dickens wrote:> On 7/17/06, Mark Shellenbaum <Mark.Shellenbaum at sun.com> 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 >
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>...] \ >... > zfs unallow <dataset> [-r] [-l] [-d] > >If we''re going to use English words, it should be "allow" and "disallow". Darren
Mark Shellenbaum wrote:> Glenn Skinner wrote: > >> The following is a nit-level comment, so I''ve directed it onl;y to you, >> rather than to the entire list. >> >> Date: Mon, 17 Jul 2006 09:57:35 -0600 >> From: Mark Shellenbaum <Mark.Shellenbaum at sun.com> >> Subject: [zfs-discuss] Proposal: delegated administration >> >> 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. >> >> ... >> 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> >> Please, can we have "disallow" instead of "unallow"? The former is a >> real word, the latter isn''t. >> >> -- Glenn >> > > The reasoning behind unallow was to imply that you are simply removing > an "allow". With *disallow* it would sound more like you are denying > a permission.Then make the removal operation another arg to "allow". Or better yet, use a pair of words where you''re not tempted to use bad English, such as "grant" and "revoke", or just use "revoke" anyway? Darren
> >PERMISSION GRANTING > > > > zfs allow [-l] [-d] <"everyone"|user|group> <ability>[,<ability>...] \ > >... > > zfs unallow <dataset> [-r] [-l] [-d] > > > > If we''re going to use English words, it should be "allow" and "disallow".The problem with ''disallow'' is that it implies precluding a behavior that would normally be allowed -- similar to allow/deny in ACLs. How about allow/revoke, or grant/revoke, or delegate/revoke? Jeff
Jeff Bonwick wrote:>>>PERMISSION GRANTING >>> >>> zfs allow [-l] [-d] <"everyone"|user|group> <ability>[,<ability>...] \ >>>... >>> zfs unallow <dataset> [-r] [-l] [-d] >>> >>> >>> >>If we''re going to use English words, it should be "allow" and "disallow". >> >> > >The problem with ''disallow'' is that it implies precluding a behavior >that would normally be allowed -- similar to allow/deny in ACLs. > >How about allow/revoke, or grant/revoke, or delegate/revoke? > >Yes, yes, no :) Darren
I like to think of delegation as being a bit different than granting permision--in fact, as a special permission that may include counts. For example, you might delegate to a manager the ability to grant select permissions. You may want to limit the number of users the manager may grant these permissions to and perhaps allow that manager to further delegate one more degree removed to project managers. Delegation then has two counts associated with it--the total number of users to which a permission may be granted and the depth of delegation permitted (often 0). Very handy when working accross trust domains, as may be the case when a resource is for open source or involves multiple departments. Bill>>>PERMISSION GRANTING >>> >>> zfs allow [-l] [-d] <"everyone"|user|group> <ability>[,<ability>...] \ >>>... >>> zfs unallow <dataset> [-r] [-l] [-d] >>> >>> >>> >>If we''re going to use English words, it should be "allow" and "disallow". >> >> > >The problem with ''disallow'' is that it implies precluding a behavior >that would normally be allowed -- similar to allow/deny in ACLs. > >How about allow/revoke, or grant/revoke, or delegate/revoke? > >Jeff > >_______________________________________________ >zfs-discuss mailing list >zfs-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060718/5c8574f0/attachment.html>
Jeff Bonwick wrote:>>> PERMISSION GRANTING >>> >>> zfs allow [-l] [-d] <"everyone"|user|group> <ability>[,<ability>...] \ >>> ... >>> zfs unallow <dataset> [-r] [-l] [-d] >>> >> If we''re going to use English words, it should be "allow" and "disallow". > > The problem with ''disallow'' is that it implies precluding a behavior > that would normally be allowed -- similar to allow/deny in ACLs. > > How about allow/revoke, or grant/revoke, or delegate/revoke?delegate/revoke gets my vote Michael
Darren Reed wrote:> > Then make the removal operation another arg to "allow". > > Or better yet, use a pair of words where you''re not tempted to use bad > English, such as "grant" and "revoke", > or just use "revoke" anyway?Grant matches what we do with authorisations in RBAC. You grant a user an authorisation to do something, you would then revoke an authorisation. -- Darren J Moffat
Bill La Forge wrote:> I like to think of delegation as being a bit different than granting > permision--in fact, as a special permission that may include counts. > > For example, you might delegate to a manager the ability to grant select > permissions. You may want to limit the number of users the manager may > grant these permissions to and perhaps allow that manager to further > delegate one more degree removed to project managers. Delegation then > has two counts associated with it--the total number of users to which a > permission may be granted and the depth of delegation permitted (often > 0). Very handy when working accross trust domains, as may be the case > when a resource is for open source or involves multiple departments.We have this concept in Solaris RBAC. For example the authorisation for SMF solaris.smf.value.cde.login allows you to change properties of the SMF service that starts dtlogin. It does not allow you to give that authorisation to anyone else. The RBAC authorisations are hierarchical so solaris.smf.value.cde would also allow you to do that but still not to give it to others. To give out to others you need the special "grant" authorisation, which in this example would be one of the following: solaris.grant # Grant all Solaris auths solaris.smf.grant # Grant all SMF auths solaris.smf.value.grant # Grant all SMF value auths solaris.smf.value.cde.grant # Grant all CDE service SMF solaris.smf.value.cde.login.grant # Grant just CDE login auth I think it would be nice if we could have this same concept in ZFS. It doesn''t have to be the same syntax but the concept. Which is what I think Bill is saying, separation of use from the ability to delegate to others. -- Darren J Moffat
Darren J Moffat wrote:> Bill La Forge wrote: >> I like to think of delegation as being a bit different than granting >> permision--in fact, as a special permission that may include counts. >> >> For example, you might delegate to a manager the ability to grant >> select permissions. You may want to limit the number of users the >> manager may grant these permissions to and perhaps allow that manager >> to further delegate one more degree removed to project managers. >> Delegation then has two counts associated with it--the total number of >> users to which a permission may be granted and the depth of delegation >> permitted (often 0). Very handy when working accross trust domains, as >> may be the case when a resource is for open source or involves >> multiple departments. > > We have this concept in Solaris RBAC. > > For example the authorisation for SMF solaris.smf.value.cde.login allows > you to change properties of the SMF service that starts dtlogin. It > does not allow you to give that authorisation to anyone else. The RBAC > authorisations are hierarchical so solaris.smf.value.cde would also > allow you to do that but still not to give it to others. > > To give out to others you need the special "grant" authorisation, which > in this example would be one of the following: > solaris.grant # Grant all Solaris auths > solaris.smf.grant # Grant all SMF auths > solaris.smf.value.grant # Grant all SMF value auths > solaris.smf.value.cde.grant # Grant all CDE service SMF > solaris.smf.value.cde.login.grant # Grant just CDE login auth > > I think it would be nice if we could have this same concept in ZFS. > It doesn''t have to be the same syntax but the concept. Which is what I > think Bill is saying, separation of use from the ability to delegate to > others. > >We could have a special permission "allow", for example that would allow this behavior. When a normal user delegates to another user they would be allowed to only hand out permissions they currently have. For example: # zfs allow joe create,destroy,allow <ds> Now as joe $ zfs allow betty create,destroy <ds> Now assuming that joe has the following permissions: create,destroy The following delegation attempt would fail $ zfs allow betty create,destroy,snapshot <ds> Since "joe" doesn''t have "snapshot", he can''t give it away. -Mark
On 7/18/06, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> Darren J Moffat wrote: > > Bill La Forge wrote: > >> I like to think of delegation as being a bit different than granting > >> permision--in fact, as a special permission that may include counts. > >> > >> For example, you might delegate to a manager the ability to grant > >> select permissions. You may want to limit the number of users the > >> manager may grant these permissions to and perhaps allow that manager > >> to further delegate one more degree removed to project managers. > >> Delegation then has two counts associated with it--the total number of > >> users to which a permission may be granted and the depth of delegation > >> permitted (often 0). Very handy when working accross trust domains, as > >> may be the case when a resource is for open source or involves > >> multiple departments. > > > > We have this concept in Solaris RBAC. > > > > For example the authorisation for SMF solaris.smf.value.cde.login allows > > you to change properties of the SMF service that starts dtlogin. It > > does not allow you to give that authorisation to anyone else. The RBAC > > authorisations are hierarchical so solaris.smf.value.cde would also > > allow you to do that but still not to give it to others. > > > > To give out to others you need the special "grant" authorisation, which > > in this example would be one of the following: > > solaris.grant # Grant all Solaris auths > > solaris.smf.grant # Grant all SMF auths > > solaris.smf.value.grant # Grant all SMF value auths > > solaris.smf.value.cde.grant # Grant all CDE service SMF > > solaris.smf.value.cde.login.grant # Grant just CDE login auth > > > > I think it would be nice if we could have this same concept in ZFS. > > It doesn''t have to be the same syntax but the concept. Which is what I > > think Bill is saying, separation of use from the ability to delegate to > > others. > > > > > > We could have a special permission "allow", for example that would allow > this behavior. When a normal user delegates to another user they would > be allowed to only hand out permissions they currently have. > > For example: > > # zfs allow joe create,destroy,allow <ds> >having a "allow" as an atribure and a command looks confusing, perhaps "grant" should be the attribute. zfs allow joe create,destroy,grant James Dickens uadmin.blogspot.com> Now as joe > > $ zfs allow betty create,destroy <ds> > > Now assuming that joe has the following permissions: > > create,destroy > > > The following delegation attempt would fail > > $ zfs allow betty create,destroy,snapshot <ds> > > Since "joe" doesn''t have "snapshot", he can''t give it away. > > > -Mark > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Mark Shellenbaum wrote:> Darren J Moffat wrote: >> Bill La Forge wrote: >>> I like to think of delegation as being a bit different than granting >>> permision--in fact, as a special permission that may include counts. >>> >>> For example, you might delegate to a manager the ability to grant >>> select permissions. You may want to limit the number of users the >>> manager may grant these permissions to and perhaps allow that manager >>> to further delegate one more degree removed to project managers. >>> Delegation then has two counts associated with it--the total number >>> of users to which a permission may be granted and the depth of >>> delegation permitted (often 0). Very handy when working accross trust >>> domains, as may be the case when a resource is for open source or >>> involves multiple departments. >> >> We have this concept in Solaris RBAC. >> >> For example the authorisation for SMF solaris.smf.value.cde.login >> allows you to change properties of the SMF service that starts >> dtlogin. It does not allow you to give that authorisation to anyone >> else. The RBAC authorisations are hierarchical so >> solaris.smf.value.cde would also allow you to do that but still not to >> give it to others. >> >> To give out to others you need the special "grant" authorisation, >> which in this example would be one of the following: >> solaris.grant # Grant all Solaris auths >> solaris.smf.grant # Grant all SMF auths >> solaris.smf.value.grant # Grant all SMF value auths >> solaris.smf.value.cde.grant # Grant all CDE service SMF >> solaris.smf.value.cde.login.grant # Grant just CDE login auth >> >> I think it would be nice if we could have this same concept in ZFS. >> It doesn''t have to be the same syntax but the concept. Which is what >> I think Bill is saying, separation of use from the ability to delegate >> to others. >> >> > > We could have a special permission "allow", for example that would allow > this behavior. When a normal user delegates to another user they would > be allowed to only hand out permissions they currently have.I really don''t like the use of allow as the zfs command and as the actual argument. Could we use grant instead, particularly since grant already has this meaning in Solaris.> For example: > > # zfs allow joe create,destroy,allow <ds># zfs allow joe create,destroy,grant <ds> However that doesn''t allow you to give the ability to grant create but not destroy. This would. # zfs allow joe create,create.grant,destroy <ds> That gives joe the ability to create stuff and to destroy but he can only delegate creation to others. Whats more that is consistent with the use of adding .grant in Solaris RBAC. A more "interesting" example might be: # zfs allow joe create,destroy,snapshot,create.grant,snapshot.grant <ds> joe$ zfs allow betty snapshot <ds> joe$ zfs allow fred create,snapshot <ds> -- Darren J Moffat
Darren J Moffat wrote:> Mark Shellenbaum wrote: >> Darren J Moffat wrote: >>> Bill La Forge wrote: >>>> I like to think of delegation as being a bit different than granting >>>> permision--in fact, as a special permission that may include counts. >>>> >>>> For example, you might delegate to a manager the ability to grant >>>> select permissions. You may want to limit the number of users the >>>> manager may grant these permissions to and perhaps allow that >>>> manager to further delegate one more degree removed to project >>>> managers. Delegation then has two counts associated with it--the >>>> total number of users to which a permission may be granted and the >>>> depth of delegation permitted (often 0). Very handy when working >>>> accross trust domains, as may be the case when a resource is for >>>> open source or involves multiple departments. >>> >>> We have this concept in Solaris RBAC. >>> >>> For example the authorisation for SMF solaris.smf.value.cde.login >>> allows you to change properties of the SMF service that starts >>> dtlogin. It does not allow you to give that authorisation to anyone >>> else. The RBAC authorisations are hierarchical so >>> solaris.smf.value.cde would also allow you to do that but still not >>> to give it to others. >>> >>> To give out to others you need the special "grant" authorisation, >>> which in this example would be one of the following: >>> solaris.grant # Grant all Solaris auths >>> solaris.smf.grant # Grant all SMF auths >>> solaris.smf.value.grant # Grant all SMF value auths >>> solaris.smf.value.cde.grant # Grant all CDE service SMF >>> solaris.smf.value.cde.login.grant # Grant just CDE login auth >>> >>> I think it would be nice if we could have this same concept in ZFS. >>> It doesn''t have to be the same syntax but the concept. Which is what >>> I think Bill is saying, separation of use from the ability to >>> delegate to others. >>> >>> >> >> We could have a special permission "allow", for example that would allow >> this behavior. When a normal user delegates to another user they would >> be allowed to only hand out permissions they currently have. > > I really don''t like the use of allow as the zfs command and as the > actual argument. Could we use grant instead, particularly since grant > already has this meaning in Solaris.Except that the permissions we have so far defined match the name of the zfs subcommand, or the property name. Using grant would violate that rule.> >> For example: >> >> # zfs allow joe create,destroy,allow <ds> > > # zfs allow joe create,destroy,grant <ds> > > However that doesn''t allow you to give the ability to grant create > but not destroy. > > This would. > > # zfs allow joe create,create.grant,destroy <ds> > > That gives joe the ability to create stuff and to destroy but > he can only delegate creation to others. > > Whats more that is consistent with the use of adding .grant in > Solaris RBAC. > > A more "interesting" example might be: > > # zfs allow joe create,destroy,snapshot,create.grant,snapshot.grant <ds> > > joe$ zfs allow betty snapshot <ds> > joe$ zfs allow fred create,snapshot <ds> > >Can grants be propagated to another user, such as. joe$ zfs allow betty snapshot,snapshot.grant <ds> betty$ zfs allow wilma snapshot <ds> -Mark
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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss