coreutils-like -i parameter, splitting permissions for various tasks
There is a serious flaw in btrfs subcommands handling. Since all of them are handled by single 'btrfs' binary, there is no way to create any protection against accidental data loss for (the only one I've found, but still DANGEROUS) 'btrfs subvolume delete'.
There are several protections that are being used for various commands. For example, with zsh having hist_ignore_space enabled I got:
alias kill=' kill'
alias halt=' halt'
alias init=' init'
alias poweroff=' poweroff'
alias reboot=' reboot'
alias shutdown=' shutdown'
alias telinit=' telinit'
so that these command are never saved into my shell history.
Other system-wide protection enabled by default might be coreutils.sh creating aliases:
alias cp=' cp --interactive --archive --backup=numbered --reflink=auto' alias mv=' mv --interactive --backup=numbered'
alias rm=' rm --interactive --one-file-system --interactive=once'
All such countermeasures reduce the probability of fatal mistakes.
There is no 'prompt before doing ANYTHING irreversible' option for btrfs, so everyone needs to take special care typing commands. Since snapshotting and managing subvolumes is some daily-routine, not anything special (like creating storage pools or managing devices), this should be more forgiving for any user errors. Since there is no other (obvious) solution, I propose makeing "subvolume delete" ask for confirmation by default, unless used with newly introduced option, like -y(--yes).
Moreover, since there might be different admin roles on the system, the btrfs-progs should be splitted into separate tools, so one could have quota-admin without permissions for managing devices, backup-admin with access to all the subvolumes or maintenance-admin that could issue scrub or rebalance volumes. For backward compatibility, these tools could be issued by 'btrfs' wrapper binary.
Signature · 1 line
Tomasz Pala <[email protected]>
Quoted 37 lines · Tomasz Pala
There is a serious flaw in btrfs subcommands handling. Since all of them are handled by single 'btrfs' binary, there is no way to create any protection against accidental data loss for (the only one I've found, but still DANGEROUS) 'btrfs subvolume delete'.
There are several protections that are being used for various commands. For example, with zsh having
hist_ignore_spaceenabled I got:alias kill=' kill'
alias halt=' halt'
alias init=' init'
alias poweroff=' poweroff'
alias reboot=' reboot'
alias shutdown=' shutdown'
alias telinit=' telinit'so that these command are never saved into my shell history.
Other system-wide protection enabled by default might be
coreutils.shcreating aliases:alias cp=' cp --interactive --archive --backup=numbered --reflink=auto' alias mv=' mv --interactive --backup=numbered'
alias rm=' rm --interactive --one-file-system --interactive=once'All such countermeasures reduce the probability of fatal mistakes.
There is no 'prompt before doing ANYTHING irreversible' option for btrfs, so everyone needs to take special care typing commands. Since snapshotting and managing subvolumes is some daily-routine, not anything special (like creating storage pools or managing devices), this should be more forgiving for any user errors. Since there is no other (obvious) solution, I propose makeing "subvolume delete" ask for confirmation by default, unless used with newly introduced option, like -y(--yes).
Quoted 6 lines
Moreover, since there might be different admin roles on the system, the btrfs-progs should be splitted into separate tools, so one could have quota-admin without permissions for managing devices, backup-admin with access to all the subvolumes or maintenance-admin that could issue scrub or rebalance volumes. For backward compatibility, these tools could be issued by 'btrfs' wrapper binary.
FWIW, I maintain a little patchset on btrfs-progs which separates specific btrfs command groups and thus can be used to set/restrict privileged access:
https://github.com/digint/btrfs-progs-btrbk
It's far from being complete, merely an ugly hack. I use it to constrain btrfs actions (issued by btrbk) on remote machines within cron jobs.
Quoted 47 lines · Axel Burri
Quoted 37 lines · Tomasz Pala
There is a serious flaw in btrfs subcommands handling. Since all of them are handled by single 'btrfs' binary, there is no way to create any protection against accidental data loss for (the only one I've found, but still DANGEROUS) 'btrfs subvolume delete'.
There are several protections that are being used for various commands. For example, with zsh having
hist_ignore_spaceenabled I got:alias kill=' kill'
alias halt=' halt'
alias init=' init'
alias poweroff=' poweroff'
alias reboot=' reboot'
alias shutdown=' shutdown'
alias telinit=' telinit'so that these command are never saved into my shell history.
Other system-wide protection enabled by default might be
coreutils.shcreating aliases:alias cp=' cp --interactive --archive --backup=numbered --reflink=auto' alias mv=' mv --interactive --backup=numbered'
alias rm=' rm --interactive --one-file-system --interactive=once'All such countermeasures reduce the probability of fatal mistakes.
There is no 'prompt before doing ANYTHING irreversible' option for btrfs, so everyone needs to take special care typing commands. Since snapshotting and managing subvolumes is some daily-routine, not anything special (like creating storage pools or managing devices), this should be more forgiving for any user errors. Since there is no other (obvious) solution, I propose makeing "subvolume delete" ask for confirmation by default, unless used with newly introduced option, like -y(--yes).
Quoted 6 lines
Moreover, since there might be different admin roles on the system, the btrfs-progs should be splitted into separate tools, so one could have quota-admin without permissions for managing devices, backup-admin with access to all the subvolumes or maintenance-admin that could issue scrub or rebalance volumes. For backward compatibility, these tools could be issued by 'btrfs' wrapper binary.
Quoted 8 lines
FWIW, I maintain a little patchset on btrfs-progs which separates specific btrfs command groups and thus can be used to set/restrict privileged access:
https://github.com/digint/btrfs-progs-btrbk
It's far from being complete, merely an ugly hack. I use it to constrain btrfs actions (issued by btrbk) on remote machines within cron jobs.
I think this is an interesting approach, the specific binaries with capabilities avoid setting up sudo. The sources can also be generated from some template, but what you have now is fine. I'm a bit concerned about the security implications as the tools would need to be limited to trusted users and up to the admin to deploy them properly, but otherwise I see the usecase and would not mind merging it.
Quoted 4 lines · Tomasz Pala
There is a serious flaw in btrfs subcommands handling. Since all of them are handled by single 'btrfs' binary, there is no way to create any protection against accidental data loss for (the only one I've found, but still DANGEROUS) 'btrfs subvolume delete'.
So, what about this:
we can add a global option to add the requested interactivity and commands that are considred dangerous will require the confimation.
alias btrfs='btrfs -i'
This would expand to 'btrfs -i subvolume delete /subvol' etc. For any command that is not dangerous, the option -i will be accepted but nothing would happen.
[...]
Quoted 4 lines
(like creating storage pools or managing devices), this should be more forgiving for any user errors. Since there is no other (obvious) solution, I propose makeing "subvolume delete" ask for confirmation by default, unless used with newly introduced option, like -y(--yes).
Does it make sense to add an option to override the -i? This would cancel the -i that would be hidden in the alias. This can be generally done by quoting the command, but the option to override -i might fit somebodys usability habits.
Either option to 'say yes to all queries' or a simple negation of -i, like -I.