Hi I think ZFS should add the concept of ownership to a ZFS filesystem, so if i create a filesystem for joe, he should be able to use his space how ever he see''s fit, if he wants to turn on compression or take 5000 snapshots its his filesystem, let him. If he wants to destroy snapshots, he created them it should be allowed, but he should not be allowed to do the same with carol''s filesystem. The current filesystem management is not fine grained enough to deal with this. Of course if we don''t assign an owner the filesystem should perform much like it does today. zfs set owner=joe pool/joe
James Dickens wrote:> Hi > > I think ZFS should add the concept of ownership to a ZFS filesystem, > so if i create a filesystem for joe, he should be able to use his > space how ever he see''s fit, if he wants to turn on compression or > take 5000 snapshots its his filesystem, let him. If he wants to > destroy snapshots, he created them it should be allowed, but he should > not be allowed to do the same with carol''s filesystem. The current > filesystem management is not fine grained enough to deal with this. Of > course if we don''t assign an owner the filesystem should perform much > like it does today.Yes we do need something like this. This is already covered by the following CRs 6280676, 6421209. -- Darren J Moffat
Hello James,
Tuesday, May 23, 2006, 6:43:11 PM, you wrote:
JD> Hi
JD> I think ZFS should add the concept of ownership to a ZFS filesystem,
JD> so if i create a filesystem for joe, he should be able to use his
JD> space how ever he see''s fit, if he wants to turn on compression
or
JD> take 5000 snapshots its his filesystem, let him. If he wants to
JD> destroy snapshots, he created them it should be allowed, but he should
JD> not be allowed to do the same with carol''s filesystem. The
current
JD> filesystem management is not fine grained enough to deal with this. Of
JD> course if we don''t assign an owner the filesystem should perform
much
JD> like it does today.
JD> zfs set owner=joe pool/joe
IIRC it''s planned - however I''m not sure it a user should be
able to
turn on compression, especially when it''s directly turned off by sys
admin.
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
On 5/23/06, Robert Milkowski <rmilkowski at task.gda.pl> wrote:> Hello James, > > Tuesday, May 23, 2006, 6:43:11 PM, you wrote: > > JD> Hi > > JD> I think ZFS should add the concept of ownership to a ZFS filesystem, > JD> so if i create a filesystem for joe, he should be able to use his > JD> space how ever he see''s fit, if he wants to turn on compression or > JD> take 5000 snapshots its his filesystem, let him. If he wants to > JD> destroy snapshots, he created them it should be allowed, but he should > JD> not be allowed to do the same with carol''s filesystem. The current > JD> filesystem management is not fine grained enough to deal with this. Of > JD> course if we don''t assign an owner the filesystem should perform much > JD> like it does today. > > JD> zfs set owner=joe pool/joe > > > IIRC it''s planned - however I''m not sure it a user should be able to > turn on compression, especially when it''s directly turned off by sys > admin. >perhaps if compression turned/forced off by the admin then it shouldn''t be alowed, but enabling compression on a filesystem that just had it off by default should be allowed but of course this complicates implementation. They could create a system wide config file disallowing compression/encryption etc. James uadmin.blogspot.com> -- > Best regards, > Robert mailto:rmilkowski at task.gda.pl > http://milek.blogspot.com > >
Darren J Moffat wrote:> James Dickens wrote: > > I think ZFS should add the concept of ownership to a ZFS filesystem, > > so if i create a filesystem for joe, he should be able to use his > > space how ever he see''s fit, if he wants to turn on compression or > > take 5000 snapshots its his filesystem, let him. If he wants to > > destroy snapshots, he created them it should be allowed, but he should > > not be allowed to do the same with carol''s filesystem. The current > > filesystem management is not fine grained enough to deal with this. Of > > course if we don''t assign an owner the filesystem should perform much > > like it does today. > > Yes we do need something like this. > > This is already covered by the following CRs 6280676, 6421209.That could be done if "zfs" would be based on ksh93... you could simply run it as "profile shell" (pfksh93) and make a profile for that user+ZFS filesystem... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
Hello James, Tuesday, May 23, 2006, 10:25:10 PM, you wrote: JD> On 5/23/06, Robert Milkowski <rmilkowski at task.gda.pl> wrote:>> Hello James, >> >> Tuesday, May 23, 2006, 6:43:11 PM, you wrote: >> >> JD> Hi >> >> JD> I think ZFS should add the concept of ownership to a ZFS filesystem, >> JD> so if i create a filesystem for joe, he should be able to use his >> JD> space how ever he see''s fit, if he wants to turn on compression or >> JD> take 5000 snapshots its his filesystem, let him. If he wants to >> JD> destroy snapshots, he created them it should be allowed, but he should >> JD> not be allowed to do the same with carol''s filesystem. The current >> JD> filesystem management is not fine grained enough to deal with this. Of >> JD> course if we don''t assign an owner the filesystem should perform much >> JD> like it does today. >> >> JD> zfs set owner=joe pool/joe >> >> >> IIRC it''s planned - however I''m not sure it a user should be able to >> turn on compression, especially when it''s directly turned off by sys >> admin. >>JD> perhaps if compression turned/forced off by the admin then it JD> shouldn''t be alowed, but enabling compression on a filesystem that JD> just had it off by default should be allowed but of course this JD> complicates implementation. They could create a system wide config JD> file disallowing compression/encryption etc. Something like ''zfs set compression=user dataset'' or instead of ''user'' -> ''allow'' -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
Hello Roland, Tuesday, May 23, 2006, 10:31:37 PM, you wrote: RM> Darren J Moffat wrote:>> James Dickens wrote: >> > I think ZFS should add the concept of ownership to a ZFS filesystem, >> > so if i create a filesystem for joe, he should be able to use his >> > space how ever he see''s fit, if he wants to turn on compression or >> > take 5000 snapshots its his filesystem, let him. If he wants to >> > destroy snapshots, he created them it should be allowed, but he should >> > not be allowed to do the same with carol''s filesystem. The current >> > filesystem management is not fine grained enough to deal with this. Of >> > course if we don''t assign an owner the filesystem should perform much >> > like it does today. >> >> Yes we do need something like this. >> >> This is already covered by the following CRs 6280676, 6421209.RM> That could be done if "zfs" would be based on ksh93... you could simply RM> run it as "profile shell" (pfksh93) and make a profile for that user+ZFS RM> filesystem... Maybe I''m missing something but it has nothing to do with ksh93 or any other shell. It should just work for a given user despite of it''s shell, etc - just uid and proper privileges. -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
Darren J Moffat wrote:> James Dickens wrote: > >> Hi >> >> I think ZFS should add the concept of ownership to a ZFS filesystem, >> so if i create a filesystem for joe, he should be able to use his >> space how ever he see''s fit, if he wants to turn on compression or >> take 5000 snapshots its his filesystem, let him. If he wants to >> destroy snapshots, he created them it should be allowed, but he should >> not be allowed to do the same with carol''s filesystem. The current >> filesystem management is not fine grained enough to deal with this. Of >> course if we don''t assign an owner the filesystem should perform much >> like it does today. > > > Yes we do need something like this. > > This is already covered by the following CRs 6280676, 6421209. >These RFE''s are currently being investigated. The basic idea is that an adminstrator will be allowed to grant specific users/groups to perform various zfs adminstrative tasks, such as create, destroy, clone, changing properties and so on. After the zfs team is in agreement as to what the interfaces should be, I will forward it to zfs-discuss for further feedback. -Mark
Roland Mainz wrote:> Darren J Moffat wrote: >> James Dickens wrote: >>> I think ZFS should add the concept of ownership to a ZFS filesystem, >>> so if i create a filesystem for joe, he should be able to use his >>> space how ever he see''s fit, if he wants to turn on compression or >>> take 5000 snapshots its his filesystem, let him. If he wants to >>> destroy snapshots, he created them it should be allowed, but he should >>> not be allowed to do the same with carol''s filesystem. The current >>> filesystem management is not fine grained enough to deal with this. Of >>> course if we don''t assign an owner the filesystem should perform much >>> like it does today. >> Yes we do need something like this. >> >> This is already covered by the following CRs 6280676, 6421209. > > That could be done if "zfs" would be based on ksh93... you could simply > run it as "profile shell" (pfksh93) and make a profile for that user+ZFS > filesystem...We already have an RBAC profile "ZFS File System Management" but that allows the user given that profile to manage ALL ZFS file systems. What this is really about is having the zfs kernel module check an ACL on the data set to determine if the user can create/snapshot/clone/destroy/ etc, also certain properties may need to be "locked". I''ve given a lot of thought to this as has Mark Shellenbaum and trust me RBAC is not the answer here and ksh93 based zfs is not going to help one way or another since this is all kernel based policy. -- Darren J Moffat
Darren J Moffat wrote:> Roland Mainz wrote: > >> Darren J Moffat wrote: >> >>> James Dickens wrote: >>> >>>> I think ZFS should add the concept of ownership to a ZFS filesystem, >>>> so if i create a filesystem for joe, he should be able to use his >>>> space how ever he see''s fit, if he wants to turn on compression or >>>> take 5000 snapshots its his filesystem, let him. If he wants to >>>> destroy snapshots, he created them it should be allowed, but he should >>>> not be allowed to do the same with carol''s filesystem. The current >>>> filesystem management is not fine grained enough to deal with this. Of >>>> course if we don''t assign an owner the filesystem should perform much >>>> like it does today. >>> >>> Yes we do need something like this. >>> >>> This is already covered by the following CRs 6280676, 6421209. >> >> >> That could be done if "zfs" would be based on ksh93... you could simply >> run it as "profile shell" (pfksh93) and make a profile for that user+ZFS >> filesystem... > > > We already have an RBAC profile "ZFS File System Management" but that > allows the user given that profile to manage ALL ZFS file systems. > > What this is really about is having the zfs kernel module check an ACL > on the data set to determine if the user can > create/snapshot/clone/destroy/ etc, also certain properties may need > to be "locked".Could it be worthwhile imposing limits, in addition to locking? For example, if I gave you the right to snapshot ~darrenm, I might want to only allow you 10 snapshots. Is that a worthwhile restriction or is it better to just let quotas take care of that? At issue here is the potential for (again :) zfs to spam df output through potentially accidental excessive use of snapshots by a user with a buggy cron job. Or maybe they have potential to be malicious through this avenue too? The point here is not to deny the action but to give it bounds. Darren
Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> writes:> > Yes we do need something like this. > > > > This is already covered by the following CRs 6280676, 6421209. > > These RFE''s are currently being investigated. The basic idea is that > an adminstrator will be allowed to grant specific users/groups to > perform various zfs adminstrative tasks, such as create, destroy, clone, > changing properties and so on. > > After the zfs team is in agreement as to what the interfaces should be, > I will forward it to zfs-discuss for further feedback.In addition to this, what I think will become necessary is a way to perform this sort of end-user zfs administration securely over the network (maybe with an RPC service secured with RPCSEC_GSS?): I don''t want to grant every single student login to the fileservers to admin their zfs filesystems ;-( Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University
Rainer Orth wrote:> Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> writes: > >>> Yes we do need something like this. >>> >>> This is already covered by the following CRs 6280676, 6421209. >> These RFE''s are currently being investigated. The basic idea is that >> an adminstrator will be allowed to grant specific users/groups to >> perform various zfs adminstrative tasks, such as create, destroy, clone, >> changing properties and so on. >> >> After the zfs team is in agreement as to what the interfaces should be, >> I will forward it to zfs-discuss for further feedback. > > In addition to this, what I think will become necessary is a way to perform > this sort of end-user zfs administration securely over the network (maybe > with an RPC service secured with RPCSEC_GSS?): I don''t want to grant every > single student login to the fileservers to admin their zfs filesystems ;-(I''m assuming you mean using zfs(1) but having a "remote" mode where you indicate the name of the server and pool. There is, sadly, the problem of mandating RPCSEC_GSS because so many people don''t have the Kerberos infrastructure setup to use it. Personally I''d be more than happy to say that if you want to use this you must use RPCSEC_GSS but that might not go down well with everyone. I do actually like your suggestion of a zfs command that talks over RPCSEC_GSS and it would work great for me since I do have Kerberos creds on the client and servers I use! However it would be really really nice if we didn''t need a special command on the client side. Particularly since it might not be a Solaris machine on the client. As it happens we have a "client" interface that doesn''t require you run Solaris on the client side or have Kerberos deployed; the web based ZFS gui that is secured by SSL. The other option is to allow users to this by doing operations in the special ".zfs" directory. This should even be possible over NFS or CIFS. For example creation, rename and delete of snapshots using normal file system tools, in .zfs/snapshot. mv seems to be able to rename a snapshot. Maybe we could have cp on a snapshot mean clone eg: $ cd .zfs/snapshot $ mv foo bar $ cp bar baz $ rm may Would rename the snapshot called foo to the snapshot called bar It would then create a clone called baz based on the snapshot bar. Finally removing the snapshot called may. Given that the .zfs directory is special we might be able to invent additional things for doing the other operations. The harder part is setting the options like share/checksum/compression etc. -- Darren J Moffat
> For example, if I gave you the right to snapshot ~darrenm, I might > want to only allow you 10 snapshots. Is that a worthwhile restriction > or is it better to just let quotas take care of that? > > At issue here is the potential for (again :) zfs to spam df output > through potentially accidental excessive use of snapshots by a > user with a buggy cron job.I''d be inclined to just let quotas take care of it, because a snapshot is really just another way of using space. As a general principle I think an operating system should restrict physical resources (disk space, physical memory, CPU time) as necessary, but not put any limits on logical resources (e.g. files per directory, mappings per address space, or integer multiplies per function call). Limits on logical resources tend to be very annoying to deal with. Jeff
Jeff Bonwick wrote:>> For example, if I gave you the right to snapshot ~darrenm, I might >> want to only allow you 10 snapshots. Is that a worthwhile restriction >> or is it better to just let quotas take care of that? >> >> At issue here is the potential for (again :) zfs to spam df output >> through potentially accidental excessive use of snapshots by a >> user with a buggy cron job. > > I''d be inclined to just let quotas take care of it, because a snapshot > is really just another way of using space. > > As a general principle I think an operating system should restrict > physical resources (disk space, physical memory, CPU time) as necessary, > but not put any limits on logical resources (e.g. files per directory, > mappings per address space, or integer multiplies per function call). > Limits on logical resources tend to be very annoying to deal with.I completely agree. Give the user a disk quota what they do with it is up to them. Uses often have different needs depending on their personal paranoid of computers and backup software and what they actually do. One user might work on only one or two files but need lots of snapshots another might have lots of files and never snapshot at all. -- Darren J Moffat
> The other option is to allow users to this by doing operations in the > special ".zfs" directory. This should even be possible over NFS or CIFS. > For example creation, rename and delete of snapshots using normal file > system tools, in .zfs/snapshot. > > mv seems to be able to rename a snapshot. Maybe we could have cp on a > snapshot mean clone eg: > $ cd .zfs/snapshot > $ mv foo bar > $ cp bar baz > $ rm may > > Would rename the snapshot called foo to the snapshot called bar > It would then create a clone called baz based on the snapshot bar. > Finally removing the snapshot called may.I had replied to another post about this but didn''t see any responses. Is this behavior of being able to manipulate the snapshots through normal file commands documented somewhere? While it''s cool, I''m a little suspicious that something I might create to guard against file system accidents (a snapshot) can itself be destroyed by an accidental file system access, not an explicit ZFS command. I also don''t quite understand why snapshot manipulation works via files only in some situations and not in others. # zfs snapshot zpool/test at snap1 # zfs snapshot zpool/test at snap2 # cd /zpool/test/.zfs/snapshot # ls snap1 a b c d e # ls -l snap2 total 5 -rw-r--r-- 1 root root 0 May 10 15:37 a -rw-r--r-- 1 root root 0 May 10 15:37 b -rw-r--r-- 1 root root 0 May 10 15:37 c -rw-r--r-- 1 root root 0 May 10 15:37 d -rw-r--r-- 1 root root 0 May 10 15:37 e # rmdir snap1 snap2 rmdir: directory "snap2": Directory is a mount point or in use # zfs destroy zpool/test at snap2 # Why can snap1 be removed directly but snap2 cannot? Thanks. -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
On Wed, May 24, 2006 at 10:38:34AM +0100, Darren J Moffat wrote:> mv seems to be able to rename a snapshot. Maybe we could have cp on a > snapshot mean clone eg: > $ cd .zfs/snapshot > $ mv foo bar > $ cp bar baz > $ rm mayHmm, why not a .clones in snapshots'' .zfs? Then: $ cd .zfs/snapshot $ mkdir foo # take snapshot $ cd foo/.zfs/clones $ mkdir bar # clone the snapshot $ mv bar <path> # set clone''s mountpoint Nico --