[btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks

[Tomasz Pala <gotar@polanet.pl>]

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.

-- 
Tomasz Pala <gotar@pld-linux.org>