On 2018-02-10 12:24, Tomasz Pala wrote: > 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.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
