Possible to undo subvol delete?

Possible to undo subvol delete?

[Shriramana Sharma]

IIUC with BtrFS while it is possible to easily undelete a file or
ordinary directory if a snapshot of the containing subvol exists, it
seems that it's not elementary to undelete a subvol itself, because
all subvols are under the root-level subvol (id 0 or 5, see my other
q) but even snapshotting the root subvol will not snapshot any subvols
under it.

So is there any way to undo a subvol delete?

[If no, then ordinary users should probably prefer regular directories
to subvols.]

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Marc MERLIN]

On Sun, Nov 30, 2014 at 09:03:14AM +0530, Shriramana Sharma wrote:
> IIUC with BtrFS while it is possible to easily undelete a file or
> ordinary directory if a snapshot of the containing subvol exists, it
> seems that it's not elementary to undelete a subvol itself, because
> all subvols are under the root-level subvol (id 0 or 5, see my other
> q) but even snapshotting the root subvol will not snapshot any subvols
> under it.
> 
> So is there any way to undo a subvol delete?

If you didn't snapshot that volume before deleting it, you're SOL.
If you snapshotted it, rename that snapshot to the other name, and
you're done.

Btrfs doesn't offer undelete, it only lets you keep multiple copies of
your data at very little cost, so you can retrieve a snapshot copy if
you deleted your current volume's data.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Possible to undo subvol delete?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On 2014-11-29 23:23, Marc MERLIN wrote:
> On Sun, Nov 30, 2014 at 09:03:14AM +0530, Shriramana Sharma wrote:
>> IIUC with BtrFS while it is possible to easily undelete a file or
>> ordinary directory if a snapshot of the containing subvol exists, it
>> seems that it's not elementary to undelete a subvol itself, because
>> all subvols are under the root-level subvol (id 0 or 5, see my other
>> q) but even snapshotting the root subvol will not snapshot any subvols
>> under it.
>>
>> So is there any way to undo a subvol delete?
>
> If you didn't snapshot that volume before deleting it, you're SOL.
> If you snapshotted it, rename that snapshot to the other name, and
> you're done.
>
> Btrfs doesn't offer undelete, it only lets you keep multiple copies of
> your data at very little cost, so you can retrieve a snapshot copy if
> you deleted your current volume's data.
>
> Marc
>
Well, in theory, if you unmount the FS _immediately_ after the subvol 
delete, without writing _anything_ else to it, it _might_ be possible to 
recover the data using some (probably almost incomprehensible) 
incantation of btrfs-find-root and btrfs recover/restore.

In practice though, for anyone who doesn't have expert level knowledge 
of the on-disk structure and fs internals, deleting a subvolume can't be 
undone.

We might want to consider adding an option to btrfs subvol del to ask 
for confirmation (or make it do so by default and add an option to 
disable asking for confirmation).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Mon, Dec 1, 2014 at 6:42 PM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
>
> We might want to consider adding an option to btrfs subvol del to ask for
> confirmation (or make it do so by default and add an option to disable
> asking for confirmation).

I already reported: https://bugzilla.kernel.org/show_bug.cgi?id=89091.
As I requested there, I prefer for confirmation by default and -f to
force otherwise, rather than behaviour of rm which requires -i to ask
confirmation.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[MegaBrutal]

2014-12-01 14:12 GMT+01:00 Austin S Hemmelgarn <ahferroin7@gmail.com>:
>
> We might want to consider adding an option to btrfs subvol del to ask for
> confirmation (or make it do so by default and add an option to disable
> asking for confirmation).
>

I've also noticed, a subvolume can just be deleted with an "rm -r",
just like an ordinary directory. I'd consider to only allow subvolume
deletions with exact "btrfs subvolume delete" commands, and they
should be protected against an ordinary "rm". There also could be a
tunable FS feature to allow or disable ordinary subvolume deletions,
which could be set or unset by btrfstune. I think a subvolume really
deserves to be treated specially over an ordinary directory.

As for undeletion, while I have no idea how to do that, I noticed they
don't get deleted immediately. With older btrfs tools (3.12), I
noticed, if I delete a subvolume and then immediately issue a "btrfs
subvolume list", my deleted subvolume is still listed with a "DELETED"
caption, and allocated space doesn't immediately gets freed if I check
with "df -m". It takes a few seconds for the DELETED entry to
disappear and the allocated space to be freed.

Re: Possible to undo subvol delete?

[Roman Mamedov]

On Mon, 1 Dec 2014 18:49:23 +0530
Shriramana Sharma <samjnaa@gmail.com> wrote:

> As I requested there, I prefer for confirmation by default and -f to
> force otherwise, rather than behaviour of rm which requires -i to ask
> confirmation.

And I prefer the current behavior (also replied on the bug).

A more sensible idea could be adding a global-level '-i' switch, same as in
'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask
confirmation on any irreversible action).

-- 
With respect,
Roman

Re: Possible to undo subvol delete?

[Roman Mamedov]

On Mon, 1 Dec 2014 14:38:16 +0100
MegaBrutal <megabrutal@gmail.com> wrote:

> I've also noticed, a subvolume can just be deleted with an "rm -r",
> just like an ordinary directory. I'd consider to only allow subvolume
> deletions with exact "btrfs subvolume delete" commands, and they

This is already the case. 'rm -r' will remove all files in a subvolume, but
the empty subvolume itself is only deletable via the 'btrfs' command.

If you want to make snapshots which can't be removed by ordinary tools, use
the 'read-only' mode when creating them.

-- 
With respect,
Roman

Re: Possible to undo subvol delete?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On 2014-12-01 08:38, MegaBrutal wrote:
> 2014-12-01 14:12 GMT+01:00 Austin S Hemmelgarn <ahferroin7@gmail.com>:
>>
>> We might want to consider adding an option to btrfs subvol del to ask for
>> confirmation (or make it do so by default and add an option to disable
>> asking for confirmation).
>>
>
> I've also noticed, a subvolume can just be deleted with an "rm -r",
> just like an ordinary directory. I'd consider to only allow subvolume
> deletions with exact "btrfs subvolume delete" commands, and they
> should be protected against an ordinary "rm". There also could be a
> tunable FS feature to allow or disable ordinary subvolume deletions,
> which could be set or unset by btrfstune. I think a subvolume really
> deserves to be treated specially over an ordinary directory.
I don't know what distro/kernel version you might be using, but every 
version of btrfs I have used required the use of 'btrfs subvol del' to 
actually delete a subvolume, even an empty one.  It would not surprise 
me though if RHEL or SuSE had patched the kernel to allow using rm on a 
subvolume.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Possible to undo subvol delete?

[Holger Hoffstätte]

On Mon, 01 Dec 2014 14:38:16 +0100, MegaBrutal wrote:

> I've also noticed, a subvolume can just be deleted with an "rm -r",
> just like an ordinary directory. I'd consider to only allow subvolume

Nope:

root>btrfs subvolume create foo
Create subvolume './foo'
root>touch foo/bla
root>ll foo 
total 0
-rw-r--r-- 1 root root 0 Dec  1 14:47 bla
root>rm -rf foo 
rm: cannot remove ‘foo’: Operation not permitted
root>

The files of the subvolume do get deleted though, but that's correct.

Not sure what you did, but what you want is already the case.

-h

Re: Possible to undo subvol delete?

[MegaBrutal]

2014-12-01 14:47 GMT+01:00 Roman Mamedov <rm@romanrm.net>:
> On Mon, 1 Dec 2014 14:38:16 +0100
> MegaBrutal <megabrutal@gmail.com> wrote:
>
>> I've also noticed, a subvolume can just be deleted with an "rm -r",
>> just like an ordinary directory. I'd consider to only allow subvolume
>> deletions with exact "btrfs subvolume delete" commands, and they
>
> This is already the case. 'rm -r' will remove all files in a subvolume, but
> the empty subvolume itself is only deletable via the 'btrfs' command.

That's great! And there is no way to protect against recursive
deletions (besides setting the subvolume read-only, as you suggested
below), as files are processes individually by "rm". But it's OK,
people should always be very careful with "rm", and it doesn't change
with btrfs. ;)


> If you want to make snapshots which can't be removed by ordinary tools, use
> the 'read-only' mode when creating them.

Yeah, good idea! Anyway, is it possible to change a read-only snapshot
to read-write and vica-versa, or you can only specify read-only while
creating them?

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Mon, Dec 1, 2014 at 7:16 PM, Roman Mamedov <rm@romanrm.net> wrote:
>
> A more sensible idea could be adding a global-level '-i' switch, same as in
> 'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask
> confirmation on any irreversible action).

Well the difference being that there doesn't seem to be any other
irreversible action from my scan of man btrfs -- am I missing
anything? This is the only thing that actually leads to loss of data.

When btrfs has so many features (esp snapshots) to prevent user
accidentally deleting data (I liked especially
http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to
be *some* modicum of support for warning against deleting a subvolume
(and it seems others agree too).

But I see what you mean in the bugzilla comment about not wanting your
existing backup snapshot scripts to fail because they don't have a -f.
At the same time, aliasing via -i on top level btrfs binary may not be
so practical here because this is the only command which will actually
use it (again, correct if wrong).

Perhaps exporting some envvar in the default shell's rc file (or
whichever file will be read only if the shell is interactive) would
work? Like in ~/.bashrc:

export BTRFS_SUBVOLUME_DELETE_CONFIRM=1

Ideas?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Mon, Dec 1, 2014 at 7:24 PM, MegaBrutal <megabrutal@gmail.com> wrote:
>
>> If you want to make snapshots which can't be removed by ordinary tools, use
>> the 'read-only' mode when creating them.
>
> Yeah, good idea! Anyway, is it possible to change a read-only snapshot
> to read-write and vica-versa, or you can only specify read-only while
> creating them?

IIUC you can only specify RO while creating but you can always cheaply
create a RW snapshot of an RO one or an RO snapshot of an RW one...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Robert White]

On 12/01/2014 08:40 AM, Shriramana Sharma wrote:
> IIUC you can only specify RO while creating but you can always cheaply
> create a RW snapshot of an RO one or an RO snapshot of an RW one...

You can turn ReadOnly status on and off (er. "true" and "false") with 
btrfs property get/set ro=true/false /path/to/subvolume

Re: Possible to undo subvol delete?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On 2014-12-01 08:54, MegaBrutal wrote:
> 2014-12-01 14:47 GMT+01:00 Roman Mamedov <rm@romanrm.net>:
>> On Mon, 1 Dec 2014 14:38:16 +0100
>> MegaBrutal <megabrutal@gmail.com> wrote:
>>
>>> I've also noticed, a subvolume can just be deleted with an "rm -r",
>>> just like an ordinary directory. I'd consider to only allow subvolume
>>> deletions with exact "btrfs subvolume delete" commands, and they
>>
>> This is already the case. 'rm -r' will remove all files in a subvolume, but
>> the empty subvolume itself is only deletable via the 'btrfs' command.
>
> That's great! And there is no way to protect against recursive
> deletions (besides setting the subvolume read-only, as you suggested
> below), as files are processes individually by "rm". But it's OK,
> people should always be very careful with "rm", and it doesn't change
> with btrfs. ;)
>
>
>> If you want to make snapshots which can't be removed by ordinary tools, use
>> the 'read-only' mode when creating them.
>
> Yeah, good idea! Anyway, is it possible to change a read-only snapshot
> to read-write and vica-versa, or you can only specify read-only while
> creating them?
>
IIRC, there is something that you can do with the properties interface.
Personally though, I just make the snapshot RW to start with, and then 
recursively make it immutable (chattr -r +I), as I never use immutable 
files for anything else, and it works on any _sane_ filesystem, not just 
btrfs.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Possible to undo subvol delete?

[David Sterba]

On Mon, Dec 01, 2014 at 08:50:09AM -0500, Austin S Hemmelgarn wrote:
> It would not surprise 
> me though if RHEL or SuSE had patched the kernel to allow using rm on a 
> subvolume.

This would be quite a big change in behaviour that we would not do
without taking it upstream first.

Re: Possible to undo subvol delete?

[David Sterba]

On Mon, Dec 01, 2014 at 08:12:02AM -0500, Austin S Hemmelgarn wrote:
> On 2014-11-29 23:23, Marc MERLIN wrote:
> > On Sun, Nov 30, 2014 at 09:03:14AM +0530, Shriramana Sharma wrote:
> >> IIUC with BtrFS while it is possible to easily undelete a file or
> >> ordinary directory if a snapshot of the containing subvol exists, it
> >> seems that it's not elementary to undelete a subvol itself, because
> >> all subvols are under the root-level subvol (id 0 or 5, see my other
> >> q) but even snapshotting the root subvol will not snapshot any subvols
> >> under it.
> >>
> >> So is there any way to undo a subvol delete?
> >
> > If you didn't snapshot that volume before deleting it, you're SOL.
> > If you snapshotted it, rename that snapshot to the other name, and
> > you're done.
> >
> > Btrfs doesn't offer undelete, it only lets you keep multiple copies of
> > your data at very little cost, so you can retrieve a snapshot copy if
> > you deleted your current volume's data.
> >
> > Marc
> >
> Well, in theory, if you unmount the FS _immediately_ after the subvol 
> delete, without writing _anything_ else to it, it _might_ be possible to 
> recover the data using some (probably almost incomprehensible) 
> incantation of btrfs-find-root and btrfs recover/restore.
> 
> In practice though, for anyone who doesn't have expert level knowledge 
> of the on-disk structure and fs internals, deleting a subvolume can't be 
> undone.

Agreed, though there's not so much magic involved. Deleting a subvolume
means removing the directory entry and the backrefrence. Undoing that
can make the subvolume live again, although the dir/name and original
parent tree cannot be reconstructed.

I'll add it to the project ideas.

Re: Possible to undo subvol delete?

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 3453 bytes --]

On Mon, Dec 01, 2014 at 10:09:44PM +0530, Shriramana Sharma wrote:
> On Mon, Dec 1, 2014 at 7:16 PM, Roman Mamedov <rm@romanrm.net> wrote:
> >
> > A more sensible idea could be adding a global-level '-i' switch, same as in
> > 'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask
> > confirmation on any irreversible action).
> 
> Well the difference being that there doesn't seem to be any other
> irreversible action from my scan of man btrfs -- am I missing
> anything? This is the only thing that actually leads to loss of data.
> 
> When btrfs has so many features (esp snapshots) to prevent user
> accidentally deleting data (I liked especially
> http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to
> be *some* modicum of support for warning against deleting a subvolume
> (and it seems others agree too).
> 
> But I see what you mean in the bugzilla comment about not wanting your
> existing backup snapshot scripts to fail because they don't have a -f.
> At the same time, aliasing via -i on top level btrfs binary may not be
> so practical here because this is the only command which will actually
> use it (again, correct if wrong).
> 
> Perhaps exporting some envvar in the default shell's rc file (or
> whichever file will be read only if the shell is interactive) would
> work? Like in ~/.bashrc:
> 
> export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
> 
> Ideas?

Never rely on aliasing or environment variables for defaults, and never
change default behavior if your releases are old enough that someone
has built scripts on top of them.  ;)

	fprintf(stderr, "Deleting subvolume '%s' in 5 seconds.\n", subvol_path);
	if (!f_flag_on_cmd_line) {
		fprintf(stderr, "If this is not what you want,\n");
		fprintf(stderr, "*** PRESS Ctrl-C TO ABORT NOW!!! ***\a\n");
		sleep(5);
	}

Of course, in an init-shell-type environment, Ctrl-C doesn't work
either...

If I had to pick the least evil, I'd go for interactive prompting by
default (do nothing if the interaction fails, e.g. no TTY) and add a
'-f'/'--force' flag to bypass the prompt.  This is consistent with the
way lvm2 and mdadm work when presented with data-losing or otherwise
questionable commands and parameters.  It will break scripts, but btrfs
users should still be expecting that for a while as undesirable default
behaviors are identified.

OTOH maybe there is no issue with the current behavior.  Only root can
delete subvolumes, and maybe we assume root knows what they're doing?

On a side note...only root can delete subvolumes, but non-root users
can create them, which results in...this:

	$ /sbin/btrfs sub create foo
	Create subvolume './foo'
	$ date > foo/bar
	$ /sbin/btrfs sub delete foo
	Transaction commit: none (default)
	Delete subvolume '/home/testuser/foo'
	ERROR: cannot delete '/home/testuser/foo' - Operation not permitted
	$ rm -rf foo
	rm: cannot remove `foo': Operation not permitted
	$ cat /proc/version
	Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014

...uh oh?

> -- 
> Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Tue, Dec 2, 2014 at 8:44 AM, Zygo Blaxell
<ce3g8jdj@umail.furryterror.org> wrote:
> This is consistent with the
> way lvm2 and mdadm work when presented with data-losing or otherwise
> questionable commands and parameters.  It will break scripts, but btrfs
> users should still be expecting that for a while as undesirable default
> behaviors are identified.

Ah so there *is* precedent for my hunch that deleting subvols should
be different than deleting ordinary files and folders... :-)

> OTOH maybe there is no issue with the current behavior.  Only root can
> delete subvolumes, and maybe we assume root knows what they're doing?

Well in office environs, where the root password is with a certain
person only, then that's fine because that person is going to be wary
of doing anything that's make others angry at them, but on single-user
systems, one's regular password *is* the root password and the
situation is such that because ordinary (and mostly non-destructive)
things like installing requires entering it, so one gets accustomed to
entering it without too much thought, leading to the requirement for
such safety nets.

(Perhaps like in banks, we should have a two-password system, one for
destructive actions, so the user is forced to apply thought to what
they are approving!)

> On a side note...only root can delete subvolumes, but non-root users
> can create them, which results in...this:

Not sure about your Debian system, but my openSUSE Tumbleweed (with
kernel 3.17.2 and btrfsprogs 3.17) requires me to enter the root
password before creating a subvol (or in fact running anything under
/sbin or /usr/sbin).

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[MegaBrutal]

2014-12-01 17:39 GMT+01:00 Shriramana Sharma <samjnaa@gmail.com>:
>
> When btrfs has so many features (esp snapshots) to prevent user
> accidentally deleting data (I liked especially
> http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to
> be *some* modicum of support for warning against deleting a subvolume
> (and it seems others agree too).
>

WOW, this is pretty neat? How can I do the same actions from the
command-line? E.g. I would be curious whether a file changed since the
last snapshot. Today I have to use traditional methods like plain "ls
-l" (in case I trust the time & file size), or "diff". But in the
video we could see a directory in a view when we only seen the changed
files. How does that YaST application do so? And is there a more
enegant way to restore files to their originals than a plain "mv"?

Re: Possible to undo subvol delete?

[MegaBrutal]

2014-12-02 4:40 GMT+01:00 Shriramana Sharma <samjnaa@gmail.com>:
>
> Well in office environs, where the root password is with a certain
> person only, then that's fine because that person is going to be wary
> of doing anything that's make others angry at them, but on single-user
> systems, one's regular password *is* the root password and the
> situation is such that because ordinary (and mostly non-destructive)
> things like installing requires entering it, so one gets accustomed to
> entering it without too much thought, leading to the requirement for
> such safety nets.
>

It reminds me of this accidental deletion:
http://serverfault.com/questions/587102/monday-morning-mistake-sudo-rm-rf-no-preserve-root

LOL at "How do you even type --no-preserve-root accidentally?! :-o".

Re: Possible to undo subvol delete?

[Marc MERLIN]

On Tue, Dec 02, 2014 at 06:33:38AM +0100, MegaBrutal wrote:
> 2014-12-01 17:39 GMT+01:00 Shriramana Sharma <samjnaa@gmail.com>:
> >
> > When btrfs has so many features (esp snapshots) to prevent user
> > accidentally deleting data (I liked especially
> > http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to
> > be *some* modicum of support for warning against deleting a subvolume
> > (and it seems others agree too).
> >
> 
> WOW, this is pretty neat? How can I do the same actions from the
> command-line? E.g. I would be curious whether a file changed since the
> last snapshot. Today I have to use traditional methods like plain "ls

It's not trivial. See
http://marc.merlins.org/perso/btrfs/2014-05.html#Btrfs-diff-Between-Snapshots

>From what I understand, the only way to do this better is to use
btrfs-send and parse the output, but that's not trivial either since
btrfs-send has lots of intermediate renames.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Possible to undo subvol delete?

[Satoru Takeuchi]

Hi,

(2014/11/30 12:33), Shriramana Sharma wrote:
> IIUC with BtrFS while it is possible to easily undelete a file or
> ordinary directory if a snapshot of the containing subvol exists, it
> seems that it's not elementary to undelete a subvol itself, because
> all subvols are under the root-level subvol (id 0 or 5, see my other
> q) but even snapshotting the root subvol will not snapshot any subvols
> under it.
>
> So is there any way to undo a subvol delete?
>
> [If no, then ordinary users should probably prefer regular directories
> to subvols.]
>

One solution is using snapper instead of using btrfs directly.
Snapper can automatically take a snapshot just before
taking/deleting snapshots. So, if you delete a snapshot
by mistake, it's still alive.

For more information, please refer to the following URLs.

https://en.opensuse.org/Portal:Snapper
http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Europe_2014_Full_system_rollback_btrfs_snapper_0.pdf

Thanks,
Satoru

Re: Possible to undo subvol delete?

[David Sterba]

On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
> > export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
> > 
> > Ideas?
> 
> Never rely on aliasing or environment variables for defaults, and never
> change default behavior if your releases are old enough that someone
> has built scripts on top of them.  ;)

Exactly.

> If I had to pick the least evil, I'd go for interactive prompting by
> default (do nothing if the interaction fails, e.g. no TTY) and add a
> '-f'/'--force' flag to bypass the prompt.

This sounds acceptable.

> This is consistent with the
> way lvm2 and mdadm work when presented with data-losing or otherwise
> questionable commands and parameters.  It will break scripts, but btrfs
> users should still be expecting that for a while as undesirable default
> behaviors are identified.

How is this going to break scripts?

> OTOH maybe there is no issue with the current behavior.  Only root can
> delete subvolumes, and maybe we assume root knows what they're doing?

With the mount option user_subvol_rm_allowed the user can delete subvols
as well, so it makes sense to add the confirmation.

> On a side note...only root can delete subvolumes, but non-root users
> can create them, which results in...this:
> 
> 	$ /sbin/btrfs sub create foo
> 	Create subvolume './foo'
> 	$ date > foo/bar
> 	$ /sbin/btrfs sub delete foo
> 	Transaction commit: none (default)
> 	Delete subvolume '/home/testuser/foo'
> 	ERROR: cannot delete '/home/testuser/foo' - Operation not permitted
> 	$ rm -rf foo
> 	rm: cannot remove `foo': Operation not permitted
> 	$ cat /proc/version
> 	Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014
> 
> ...uh oh?

That's how it works now. I'd like to enable the user to delete their
subvolumes even without the user_subvol_rm_allowed option someday.

Re: Possible to undo subvol delete?

[David Sterba]

On Tue, Dec 02, 2014 at 09:10:15AM +0530, Shriramana Sharma wrote:
> > On a side note...only root can delete subvolumes, but non-root users
> > can create them, which results in...this:
> 
> Not sure about your Debian system, but my openSUSE Tumbleweed (with
> kernel 3.17.2 and btrfsprogs 3.17) requires me to enter the root
> password before creating a subvol (or in fact running anything under
> /sbin or /usr/sbin).

Works for me without the root password on a Tumbleweed installation
(without apparmor/selinux).

Re: Possible to undo subvol delete?

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
> > > export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
> > > 
> > > Ideas?
> > 
> > Never rely on aliasing or environment variables for defaults, and never
> > change default behavior if your releases are old enough that someone
> > has built scripts on top of them.  ;)
> 
> Exactly.
> 
> > If I had to pick the least evil, I'd go for interactive prompting by
> > default (do nothing if the interaction fails, e.g. no TTY) and add a
> > '-f'/'--force' flag to bypass the prompt.
> 
> This sounds acceptable.
> 
> > This is consistent with the
> > way lvm2 and mdadm work when presented with data-losing or otherwise
> > questionable commands and parameters.  It will break scripts, but btrfs
> > users should still be expecting that for a while as undesirable default
> > behaviors are identified.
> 
> How is this going to break scripts?

   Any script which relies on being able to delete subvolumes in
unattended operation will now require modification to use -f.

   Hugo.

-- 
Hugo Mills             | Unix: For controlling fungal diseases in crops
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: 65E74AC0          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Possible to undo subvol delete?

[Shriramana Sharma]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 478 bytes --]

On Tue, Dec 2, 2014 at 6:26 PM, David Sterba <dsterba@suse.cz> wrote:
>
> Works for me without the root password on a Tumbleweed installation
> (without apparmor/selinux).

Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi
<takeuchi_satoru@jp.fujitsu.com> wrote:
>
> Snapper can automatically take a snapshot just before
> taking/deleting snapshots. So, if you delete a snapshot
> by mistake, it's still alive.

Sorta contradicts the whole point of deleting a snapshot, no? Or is it
some sort of trash vs (real) delete mechanism?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > On a side note...only root can delete subvolumes, but non-root users
> > can create them, which results in...this:
> > 
> > 	$ /sbin/btrfs sub create foo
> > 	Create subvolume './foo'
> > 	$ date > foo/bar
> > 	$ /sbin/btrfs sub delete foo
> > 	Transaction commit: none (default)
> > 	Delete subvolume '/home/testuser/foo'
> > 	ERROR: cannot delete '/home/testuser/foo' - Operation not permitted
> > 	$ rm -rf foo
> > 	rm: cannot remove `foo': Operation not permitted
> > 	$ cat /proc/version
> > 	Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014
> > 
> > ...uh oh?
> 
> That's how it works now. I'd like to enable the user to delete their
> subvolumes even without the user_subvol_rm_allowed option someday.

That seems...odd.  It should be symmetrical, i.e. if you can create a
subvol you should be able to delete it, and if can't delete a subvol
then you shouldn't be able to create them either.  I can imagine
quite a bit of havoc could be wrought by an unprivileged user creating
subvols indiscriminately (or in various specific, targeted locations).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Possible to undo subvol delete?

[Satoru Takeuchi]

(2014/12/03 0:17), Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi
> <takeuchi_satoru@jp.fujitsu.com> wrote:
>>
>> Snapper can automatically take a snapshot just before
>> taking/deleting snapshots. So, if you delete a snapshot
>> by mistake, it's still alive.
>
> Sorta contradicts the whole point of deleting a snapshot, no? Or is it
> some sort of trash vs (real) delete mechanism?
>

It's not a Btrfs itself's feature. It's a snapper's feature.
It works as a helper of snapshot management.

1. You takes /snap by "snapper create" command.
2. You delete /snap by "snapper delete" command by mistake.
    Then snapper takes a "pre" snapshot just before deleting
    /snap.
3. Now /snap is deleted, however, a "pre" snapshot which is
    the same as /snap before deleting, is still alive.

I don't know how Btrfs itself undo the deletion of a snapshot.
It works if you manages snapshots not by btrfs directly,
but by snapper.

If I misunderstanding something, sorry for noise.

Thanks,
Satoru

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi
<takeuchi_satoru@jp.fujitsu.com> wrote:
> 2. You delete /snap by "snapper delete" command by mistake.
>    Then snapper takes a "pre" snapshot just before deleting
>    /snap.
> 3. Now /snap is deleted, however, a "pre" snapshot which is
>    the same as /snap before deleting, is still alive.
>
> I don't know how Btrfs itself undo the deletion of a snapshot.
> It works if you manages snapshots not by btrfs directly,
> but by snapper.
>
> If I misunderstanding something, sorry for noise.

No nothing misunderstood. Excellent illustration. So using snapper is
sorta like using the higher-level trash instead of lower-level rm, so
that even after we "delete", it's still available...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[David Sterba]

On Tue, Dec 02, 2014 at 02:09:45PM +0000, Hugo Mills wrote:
> On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
> > > > export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
> > > > 
> > > > Ideas?
> > > 
> > > Never rely on aliasing or environment variables for defaults, and never
> > > change default behavior if your releases are old enough that someone
> > > has built scripts on top of them.  ;)
> > 
> > Exactly.
> > 
> > > If I had to pick the least evil, I'd go for interactive prompting by
> > > default (do nothing if the interaction fails, e.g. no TTY) and add a
> > > '-f'/'--force' flag to bypass the prompt.
> > 
> > This sounds acceptable.
> > 
> > > This is consistent with the
> > > way lvm2 and mdadm work when presented with data-losing or otherwise
> > > questionable commands and parameters.  It will break scripts, but btrfs
> > > users should still be expecting that for a while as undesirable default
> > > behaviors are identified.
> > 
> > How is this going to break scripts?
> 
>    Any script which relies on being able to delete subvolumes in
> unattended operation will now require modification to use -f.

Even with the tty/interactive shell detection in place? Maybe I
understood the reference to lvm/mdadm tools wrong. My idea is that the
scripts would work as now, no prompts there.

Re: Possible to undo subvol delete?

[David Sterba]

On Tue, Dec 02, 2014 at 10:25:55AM -0500, Zygo Blaxell wrote:
> On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > > On a side note...only root can delete subvolumes, but non-root users
> > > can create them, which results in...this:
> > > 
> > > 	$ /sbin/btrfs sub create foo
> > > 	Create subvolume './foo'
> > > 	$ date > foo/bar
> > > 	$ /sbin/btrfs sub delete foo
> > > 	Transaction commit: none (default)
> > > 	Delete subvolume '/home/testuser/foo'
> > > 	ERROR: cannot delete '/home/testuser/foo' - Operation not permitted
> > > 	$ rm -rf foo
> > > 	rm: cannot remove `foo': Operation not permitted
> > > 	$ cat /proc/version
> > > 	Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014
> > > 
> > > ...uh oh?
> > 
> > That's how it works now. I'd like to enable the user to delete their
> > subvolumes even without the user_subvol_rm_allowed option someday.
> 
> That seems...odd.  It should be symmetrical, i.e. if you can create a
> subvol you should be able to delete it, and if can't delete a subvol
> then you shouldn't be able to create them either.

It should and I don't know the exact reasons why it's been restricted.
AFAICS it should be safe to enable the user_subvol_rm_allowed mode by
default.

> I can imagine
> quite a bit of havoc could be wrought by an unprivileged user creating
> subvols indiscriminately (or in various specific, targeted locations).

Is this different from creating directories the same way?

There is a difference in metadata consumption between subvolume and
directory, but this would lead to "just" ENOSPC.

Re: Possible to undo subvol delete?

[David Sterba]

On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 6:26 PM, David Sterba <dsterba@suse.cz> wrote:
> >
> > Works for me without the root password on a Tumbleweed installation
> > (without apparmor/selinux).
> 
> Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?

The context was 'does creating a subvolume require root password'.

Re: Possible to undo subvol delete?

[David Sterba]

On Tue, Dec 02, 2014 at 04:11:54PM +0900, Satoru Takeuchi wrote:
> Hi,
> 
> (2014/11/30 12:33), Shriramana Sharma wrote:
> > IIUC with BtrFS while it is possible to easily undelete a file or
> > ordinary directory if a snapshot of the containing subvol exists, it
> > seems that it's not elementary to undelete a subvol itself, because
> > all subvols are under the root-level subvol (id 0 or 5, see my other
> > q) but even snapshotting the root subvol will not snapshot any subvols
> > under it.
> >
> > So is there any way to undo a subvol delete?
> >
> > [If no, then ordinary users should probably prefer regular directories
> > to subvols.]
> >
> 
> One solution is using snapper instead of using btrfs directly.
> Snapper can automatically take a snapshot just before
> taking/deleting snapshots. So, if you delete a snapshot
> by mistake, it's still alive.

Although snapper can create a pre/post pair of snapsthots for a given
command 'snapper create -c "a command"', running subvolume deletion in
place of 'a command' does not make sense to me.

It's not clear how you intend to use snapper here. Let's say I'll
configure it for some subvolume, turn on periodic snapshots and also
create my own snapshots. The periodic (timeline) snapshots are created
every hour, but what if I create my own snapshot, delete it accidentaly
... how does the snapper-snapshots help here?

To be perfectly safe from accidental snapshot deletion in general, I'd
have to always create two instances, and move one somewhere safe.

Re: Possible to undo subvol delete?

[David Sterba]

On Wed, Dec 03, 2014 at 09:11:48AM +0900, Satoru Takeuchi wrote:
> It's not a Btrfs itself's feature. It's a snapper's feature.
> It works as a helper of snapshot management.
> 
> 1. You takes /snap by "snapper create" command.
> 2. You delete /snap by "snapper delete" command by mistake.
>     Then snapper takes a "pre" snapshot just before deleting
>     /snap.
> 3. Now /snap is deleted, however, a "pre" snapshot which is
>     the same as /snap before deleting, is still alive.

Can you please post exact commands how you achieve that?

The 'create' subcommand may take a --type parameter, without it it
creates 'single', and does not create pre or post snapshots
automatically.

Re: Possible to undo subvol delete?

[David Sterba]

On Wed, Dec 03, 2014 at 08:05:08AM +0530, Shriramana Sharma wrote:
> On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi
> <takeuchi_satoru@jp.fujitsu.com> wrote:
> > 2. You delete /snap by "snapper delete" command by mistake.
> >    Then snapper takes a "pre" snapshot just before deleting
> >    /snap.
> > 3. Now /snap is deleted, however, a "pre" snapshot which is
> >    the same as /snap before deleting, is still alive.
> >
> > I don't know how Btrfs itself undo the deletion of a snapshot.
> > It works if you manages snapshots not by btrfs directly,
> > but by snapper.
> >
> > If I misunderstanding something, sorry for noise.
> 
> No nothing misunderstood. Excellent illustration. So using snapper is
> sorta like using the higher-level trash instead of lower-level rm, so
> that even after we "delete", it's still available...

I think there's some confusion, please refer to snapper documentation.

Re: Possible to undo subvol delete?

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

On Wed, Dec 03, 2014 at 07:48:43PM +0100, David Sterba wrote:
> On Tue, Dec 02, 2014 at 10:25:55AM -0500, Zygo Blaxell wrote:
> > On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > > > On a side note...only root can delete subvolumes, but non-root users
> > > > can create them, which results in...this:
> > > > 
> > > > 	$ /sbin/btrfs sub create foo
> > > > 	Create subvolume './foo'
> > > > 	$ date > foo/bar
> > > > 	$ /sbin/btrfs sub delete foo
> > > > 	Transaction commit: none (default)
> > > > 	Delete subvolume '/home/testuser/foo'
> > > > 	ERROR: cannot delete '/home/testuser/foo' - Operation not permitted
> > > > 	$ rm -rf foo
> > > > 	rm: cannot remove `foo': Operation not permitted
> > > > 	$ cat /proc/version
> > > > 	Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014
> > > > 
> > > > ...uh oh?
> > > 
> > > That's how it works now. I'd like to enable the user to delete their
> > > subvolumes even without the user_subvol_rm_allowed option someday.
> > 
> > That seems...odd.  It should be symmetrical, i.e. if you can create a
> > subvol you should be able to delete it, and if can't delete a subvol
> > then you shouldn't be able to create them either.
> 
> It should and I don't know the exact reasons why it's been restricted.
> AFAICS it should be safe to enable the user_subvol_rm_allowed mode by
> default.
> 
> > I can imagine
> > quite a bit of havoc could be wrought by an unprivileged user creating
> > subvols indiscriminately (or in various specific, targeted locations).
> 
> Is this different from creating directories the same way?

'rmdir' doesn't know how to delete an empty subvolume, so neither does
'rm -rf', 'rsync --delete', or probably a thousand other independently
developed file-handling admin tools.

	buildbot:~# btrfs sub create /tmp/foo
	Create subvolume '/tmp/foo'
	buildbot:~# rmdir /tmp/foo
	rmdir: failed to remove `/tmp/foo': Operation not permitted

It seems unreasonable to require all the existing admin tools to learn
a new way to delete something that a non-root user can create, when we
could just teach btrfs rmdir to delete subvols instead.

> There is a difference in metadata consumption between subvolume and
> directory, but this would lead to "just" ENOSPC.

There's another subtle havoc-wreaking semantic difference between a
directory and a subvolume:  if a user has an open file on a subvolume,
the file can be deleted, but the subvolume can't:

	buildbot:~# cd /tmp/foo
	buildbot:/tmp/foo# ls -l
	total 0
	buildbot:/tmp/foo# exec 9>file
	buildbot:/tmp/foo# date >&9
	buildbot:/tmp/foo# cat file
	Wed Dec  3 14:40:24 EST 2014
	buildbot:/tmp/foo# rm file
	buildbot:/tmp/foo# cd ..
	buildbot:/tmp# ls foo/
	buildbot:/tmp# btrfs sub del foo
	Transaction commit: none (default)
	Delete subvolume '/tmp/foo'
	ERROR: cannot delete '/tmp/foo' - Device or resource busy

Close the file and subvol del works again:

	buildbot:/tmp# exec 9>&-
	buildbot:/tmp# btrfs sub del foo
	Transaction commit: none (default)
	Delete subvolume '/tmp/foo'
	buildbot:/tmp# ls foo/
	ls: cannot access foo/: No such file or directory

	buildbot:/tmp# cat /proc/version
	Linux version 3.17.2-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Thu Nov 13 21:57:39 EST 2014

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Possible to undo subvol delete?

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

On Wed, Dec 03, 2014 at 07:26:33PM +0100, David Sterba wrote:
> On Tue, Dec 02, 2014 at 02:09:45PM +0000, Hugo Mills wrote:
> > On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > > On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
> > > > > export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
> > > > > 
> > > > > Ideas?
> > > > 
> > > > Never rely on aliasing or environment variables for defaults, and never
> > > > change default behavior if your releases are old enough that someone
> > > > has built scripts on top of them.  ;)
> > > 
> > > Exactly.
> > > 
> > > > If I had to pick the least evil, I'd go for interactive prompting by
> > > > default (do nothing if the interaction fails, e.g. no TTY) and add a
> > > > '-f'/'--force' flag to bypass the prompt.
> > > 
> > > This sounds acceptable.
> > > 
> > > > This is consistent with the
> > > > way lvm2 and mdadm work when presented with data-losing or otherwise
> > > > questionable commands and parameters.  It will break scripts, but btrfs
> > > > users should still be expecting that for a while as undesirable default
> > > > behaviors are identified.
> > > 
> > > How is this going to break scripts?
> > 
> >    Any script which relies on being able to delete subvolumes in
> > unattended operation will now require modification to use -f.
> 
> Even with the tty/interactive shell detection in place? Maybe I
> understood the reference to lvm/mdadm tools wrong. My idea is that the
> scripts would work as now, no prompts there.

How do we reliably distinguish between "running in a script
interactively", "running in a script non-interactively", and "running
interactively"?

I could easily run a script from the command line that creates and
destroys subvols and runs for days or weeks (in fact, I quite often do).
It would be a significant productivity hit if an upgrade made it stop
every night waiting for confirmation from a user who went home hours
ago and won't be back for hours more.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Possible to undo subvol delete?

[Satoru Takeuchi]

Hi David,

(2014/12/04 4:12), David Sterba wrote:
> On Wed, Dec 03, 2014 at 09:11:48AM +0900, Satoru Takeuchi wrote:
>> It's not a Btrfs itself's feature. It's a snapper's feature.
>> It works as a helper of snapshot management.
>>
>> 1. You takes /snap by "snapper create" command.
>> 2. You delete /snap by "snapper delete" command by mistake.
>>      Then snapper takes a "pre" snapshot just before deleting
>>      /snap.
>> 3. Now /snap is deleted, however, a "pre" snapshot which is
>>      the same as /snap before deleting, is still alive.
>
> Can you please post exact commands how you achieve that?
>
> The 'create' subcommand may take a --type parameter, without it it
> creates 'single', and does not create pre or post snapshots
> automatically.
>

Oh, I misunderstood the concept of snapper and my explanation
was wrong. I apologize you, David and Shriramana.

I confused taking automatic pre/post snapshots at YAST and
something and on deleting snapshots. "snapper delete" doesn't
take "pre" snapshot.

Thanks,
Satoru

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Thu, Dec 4, 2014 at 12:23 AM, David Sterba <dsterba@suse.cz> wrote:
> On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote:
>> On Tue, Dec 2, 2014 at 6:26 PM, David Sterba <dsterba@suse.cz> wrote:
>> >
>> > Works for me without the root password on a Tumbleweed installation
>> > (without apparmor/selinux).
>>
>> Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?
>
> The context was 'does creating a subvolume require root password'.

Well I don't know about you, but I'm just running an openSUSE 13.2
system updated to Tumbleweed here, and even if I just hit "btrfs"
enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I
am getting:

$ btrfs
Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may
require superuser privileges (eg. root).
$

... so what to say of btrfs subvol, whether followed by crea or del!

On Kubuntu Trusty, doing the above at least gives me the help list of
btrfs subcommands and only when I try to execute some actual *action*
which requires privileges (like accessing some root-read-only file or
such) do I get an error message for not using sudo. For some (wierd)
reason SuSE (possibly thinking it's being helpful) is requiring me to
use sudo and enter password for even just *running* the btrfs
executable. If there were a way to disable this and/or get the Kubuntu
behaviour it'd be great (but of course this is not a SuSE forum!).

What seems weird to me here is that it says it *may* require root
privileges but simply drops me back to the prompt -- it doesn't seem
to check whether the executable *actually* requires root permission.
Granted, if it's under /sbin or /ust/sbin, it probably does, but the
wording is quite strange, and the behaviour stranger.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

On 2014-12-04 09:06, Shriramana Sharma wrote:
> On Thu, Dec 4, 2014 at 12:23 AM, David Sterba <dsterba@suse.cz> wrote:
>> On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote:
>>> On Tue, Dec 2, 2014 at 6:26 PM, David Sterba <dsterba@suse.cz> wrote:
>>>>
>>>> Works for me without the root password on a Tumbleweed installation
>>>> (without apparmor/selinux).
>>>
>>> Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?
>>
>> The context was 'does creating a subvolume require root password'.
>
> Well I don't know about you, but I'm just running an openSUSE 13.2
> system updated to Tumbleweed here, and even if I just hit "btrfs"
> enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I
> am getting:
>
> $ btrfs
> Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may
> require superuser privileges (eg. root).
> $
>
> ... so what to say of btrfs subvol, whether followed by crea or del!
>
> On Kubuntu Trusty, doing the above at least gives me the help list of
> btrfs subcommands and only when I try to execute some actual *action*
> which requires privileges (like accessing some root-read-only file or
> such) do I get an error message for not using sudo. For some (wierd)
> reason SuSE (possibly thinking it's being helpful) is requiring me to
> use sudo and enter password for even just *running* the btrfs
> executable. If there were a way to disable this and/or get the Kubuntu
> behaviour it'd be great (but of course this is not a SuSE forum!).
>
> What seems weird to me here is that it says it *may* require root
> privileges but simply drops me back to the prompt -- it doesn't seem
> to check whether the executable *actually* requires root permission.
> Granted, if it's under /sbin or /ust/sbin, it probably does, but the
> wording is quite strange, and the behaviour stranger.
>
AFAIK, the behavior is something in whatever patched version of whatever 
shell SuSE uses by default (IIRC, it's bash, but I'm not 100% certain 
about that).  I would go looking in /etc/profile and the other system 
wide startup files for that shell to see if you could override the 
behavior there.  It may also be something SELinux or file permissions 
related though.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Possible to undo subvol delete?

[David Sterba]

On Thu, Dec 04, 2014 at 07:36:34PM +0530, Shriramana Sharma wrote:
> Well I don't know about you, but I'm just running an openSUSE 13.2
> system updated to Tumbleweed here, and even if I just hit "btrfs"
> enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I
> am getting:
> 
> $ btrfs
> Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may
> require superuser privileges (eg. root).
> $
> 
> ... so what to say of btrfs subvol, whether followed by crea or del!

Oh I see. That must be some clever shell addon that prints that if you
don't have /sbin in PATH and try to call a command from that path.

Re: Possible to undo subvol delete?

[David Sterba]

On Wed, Dec 03, 2014 at 02:54:14PM -0500, Zygo Blaxell wrote:
> > Even with the tty/interactive shell detection in place? Maybe I
> > understood the reference to lvm/mdadm tools wrong. My idea is that the
> > scripts would work as now, no prompts there.
> 
> How do we reliably distinguish between
> "running in a script interactively",
> "running in a script non-interactively",
> and "running interactively"?

The first choice is to use isatty() function, but this would not be
enough to detect #1, which would require an extra option to force the
itneractive mode.

> I could easily run a script from the command line that creates and
> destroys subvols and runs for days or weeks (in fact, I quite often do).
> It would be a significant productivity hit if an upgrade made it stop
> every night waiting for confirmation from a user who went home hours
> ago and won't be back for hours more.

Yeah, we want to avoid such surprises. Besides isatty, there could be
more shell magic to detect the interactive mode reliably, I don't know.

Re: Possible to undo subvol delete?

[Shriramana Sharma]

David,

I'm just running default openSUSE 13.2 now (had to reinstall for other
reasons) and it's there. It's not something I added. Given that you're
also on either openSUSE or SLED/SLES, I'd expect your system to act
similarly as well. If not, it's downright curious.

I guess I'll ask around on the openSUSE Forum...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Shriramana Sharma]

OK so from https://forums.opensuse.org/showthread.php/440209-ifconfig
I learnt that it's because /sbin, /usr/sbin etc is not on the normal
user's path on openSUSE (they are, on Kubuntu). Adding them to PATH
fixes the situation. (I wasn't even able to do ifconfig without giving
the password. No idea why this is the openSUSE default...)


-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On 2014-12-05 13:11, Shriramana Sharma wrote:
> OK so from https://forums.opensuse.org/showthread.php/440209-ifconfig
> I learnt that it's because /sbin, /usr/sbin etc is not on the normal
> user's path on openSUSE (they are, on Kubuntu). Adding them to PATH
> fixes the situation. (I wasn't even able to do ifconfig without giving
> the password. No idea why this is the openSUSE default...)
Probably because OpenSUSE/SLES are designed as enterprise distributions, 
and their primary use case is having a very small number of sysadmins 
and a potentially large number of normal users.  Ubuntu et al. are 
designed primarily for PC's, where everyone is assumed to be equivalent 
to an administrator.  Personally, I prefer a somewhat hybrid approach 
where everyone has *sbin in their path, but file permissions are used to 
control what non-administrators can run.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Possible to undo subvol delete?

[Shriramana Sharma]

On Mon, Dec 8, 2014 at 6:31 PM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> Personally, I prefer a somewhat hybrid approach where everyone has *sbin in
> their path, but file permissions are used to control what non-administrators
> can run.

This is exactly the same approach as Ubuntu, since non-superuser can't
really do anything active (whether creating or deleting) with */sbin
commands, but only querying (like ifconfig, btrfs subvol list etc). So
this is not really hybrid of anything it seems.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On 2014-12-08 09:16, Shriramana Sharma wrote:
> On Mon, Dec 8, 2014 at 6:31 PM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> Personally, I prefer a somewhat hybrid approach where everyone has *sbin in
>> their path, but file permissions are used to control what non-administrators
>> can run.
>
> This is exactly the same approach as Ubuntu, since non-superuser can't
> really do anything active (whether creating or deleting) with */sbin
> commands, but only querying (like ifconfig, btrfs subvol list etc). So
> this is not really hybrid of anything it seems.
>
IIRC, Ubuntu relies on the fact that normal users don't have the 
capabilities required for the privileged operations, as opposed to just 
not letting them run the binaries at all.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]