On Sun, Feb 11, 2018 at 08:04:39PM +0100, Axel Burri wrote: > > > 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.
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. -- 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
