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

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

[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_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>

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

[Axel Burri]

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.

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

[David Sterba]

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.

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

[David Sterba]

On Sat, Feb 10, 2018 at 12:24:41PM +0100, 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'.

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.

[...]
> (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.