Re: [zfs-discuss] Proposal: delegated administration
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 sendsend 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
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 [EMAIL PROTECTED] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
On 7/18/06, Mark Shellenbaum [EMAIL PROTECTED] 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@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
Re: [zfs-discuss] Proposal: delegated administration
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. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 sendsend 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,
Re: [zfs-discuss] Proposal: delegated administration
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 [EMAIL PROTECTED] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: delegated administration
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 sendsend 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