Re: [zfs-discuss] Proposal: delegated administration

2006-07-25 Thread Mark Shellenbaum


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

2006-07-24 Thread Darren J Moffat

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

2006-07-24 Thread Mark Shellenbaum

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

2006-07-18 Thread Darren Reed

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

2006-07-18 Thread Darren Reed

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

2006-07-18 Thread Darren Reed

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

2006-07-18 Thread michael schuster

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

2006-07-18 Thread James Dickens

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

2006-07-17 Thread Bart Smaalders

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

2006-07-17 Thread Mark Shellenbaum

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

2006-07-17 Thread Matthew Ahrens
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

2006-07-17 Thread Bart Smaalders

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

2006-07-17 Thread Nicolas Williams
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

2006-07-17 Thread James Dickens

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

2006-07-17 Thread Mark Shellenbaum

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

2006-07-17 Thread Mark Shellenbaum

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