Re: [zfs-discuss] Re: Making 'zfs destroy' safer
Chris Gerhard wrote: You are not alone. My preference would be for an optional -t option to zfs destroy: zfs destroy -t snapshot tank/[EMAIL PROTECTED] or zfs destroy -t snapshot -r tank/fs would delete all the snapshots below tank/fs I agree since that would fit nicely with the existing CLI model. This is much nicer than the proposal of separate destroy verbs for each object type. It is is important to use this style because otherwise we restrict new object types and needlessly complicate the cli over time. On the other hand personally I just don't see the need for this since the @ char isn't special to the shell so I don't see where the original problem came from. One thing that might help here, when not running as root or as a user with ZFS File System Management RBAC profile, is user delegation. This will allow you to run the script as user that can only do certain operations to filesystems that they own or have been delegated specific access to operate on. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Making 'zfs destroy' safer
On the other hand personally I just don't see the need for this since the @ char isn't special to the shell so I don't see where the original problem came from. I never actually *had* a problem, I am just nervous about it. And yes, @ is not special for classical shells, but it's still more special than alphanumerics or '/', and probably more likely to *be* special in some languages/alternate shells. Then there is the seemingly trivial issue of the physical keyboard layout. The most common layout will tend to make you use the right shift key in order to type the @, in a particular sequence such that a slight slip of the finger there and *kaboom*, you have lost your (and/or everybody else's) data by accidentally hitting enter instead of shift. One can of course protect against this by writing commands backwards and such, which is what I do for cases like this along with SQL DELETE statements, but to me it just feels unnecessarily dangerous. One thing that might help here, when not running as root or as a user with ZFS File System Management RBAC profile, is user delegation. This will allow you to run the script as user that can only do certain operations to filesystems that they own or have been delegated specific access to operate on. On the other than a very minor modification to the command line tool gets you a pretty significant payoff without complicating things. It will affect the safety of the out-of-the-box tool, regardless of the local policy for privilege delegation. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org signature.asc Description: OpenPGP digital signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Making 'zfs destroy' safer
Actually, if your zfs filesystem has snapshots zfs will complain that the fs can't be destroyed (or that you have to use the -f switch to force it). So the first thing I do when making a new filesystem is create a snapshot to protect me from destroying a filesystem :) On 5/21/07, Peter Schuller [EMAIL PROTECTED] wrote: On the other hand personally I just don't see the need for this since the @ char isn't special to the shell so I don't see where the original problem came from. I never actually *had* a problem, I am just nervous about it. And yes, @ is not special for classical shells, but it's still more special than alphanumerics or '/', and probably more likely to *be* special in some languages/alternate shells. Then there is the seemingly trivial issue of the physical keyboard layout. The most common layout will tend to make you use the right shift key in order to type the @, in a particular sequence such that a slight slip of the finger there and *kaboom*, you have lost your (and/or everybody else's) data by accidentally hitting enter instead of shift. One can of course protect against this by writing commands backwards and such, which is what I do for cases like this along with SQL DELETE statements, but to me it just feels unnecessarily dangerous. One thing that might help here, when not running as root or as a user with ZFS File System Management RBAC profile, is user delegation. This will allow you to run the script as user that can only do certain operations to filesystems that they own or have been delegated specific access to operate on. On the other than a very minor modification to the command line tool gets you a pretty significant payoff without complicating things. It will affect the safety of the out-of-the-box tool, regardless of the local policy for privilege delegation. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ 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
[zfs-discuss] Re: Making 'zfs destroy' safer
You are not alone. My preference would be for an optional -t option to zfs destroy: zfs destroy -t snapshot tank/[EMAIL PROTECTED] or zfs destroy -t snapshot -r tank/fs would delete all the snapshots below tank/fs This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
