[PATCH] btrfs-progs: allow "no" to disable compression for convenience

[Satoru Takeuchi]

It's messy to use "" to disable compression. Introduce the new value "no"
which can also be used for this purpose.

Signed-off-by: Satoru Takeuchi 
---
 Documentation/btrfs-property.asciidoc | 2 +-
 props.c   | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/btrfs-property.asciidoc 
b/Documentation/btrfs-property.asciidoc
index 7ed6a7d..97b90d6 100644
--- a/Documentation/btrfs-property.asciidoc
+++ b/Documentation/btrfs-property.asciidoc
@@ -43,7 +43,7 @@ read-only flag of subvolume: true or false
 label
 label of device
 compression
-compression setting for an inode: lzo, zlib, zstd, or "" (empty string)
+compression setting for an inode: lzo, zlib, zstd, no, or "" (empty string). 
Both no and "" are for disabling compression.
 
 *list* [-t ] ::
 Lists available properties with their descriptions for the given object.
diff --git a/props.c b/props.c
index a7e3e96..a2df868 100644
--- a/props.c
+++ b/props.c
@@ -142,9 +142,11 @@ static int prop_compression(enum prop_object_type type,
memcpy(xattr_name + XATTR_BTRFS_PREFIX_LEN, name, strlen(name));
xattr_name[XATTR_BTRFS_PREFIX_LEN + strlen(name)] = '\0';
 
-   if (value)
+   if (value) {
+   if (!strcmp(value, "no"))
+   value = "";
sret = fsetxattr(fd, xattr_name, value, strlen(value), 0);
-   else
+   } else
sret = fgetxattr(fd, xattr_name, NULL, 0);
if (sret < 0) {
ret = -errno;
-- 
2.7.4

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

Re: subvolume list as user?

[Goffredo Baroncelli]

On 09/16/2017 04:37 PM, Ulli Horlacher wrote:
> On Sat 2017-09-16 (14:39), Hans van Kranenburg wrote:
>> On 09/16/2017 11:45 AM, Ulli Horlacher wrote:
>>
>>> Every user can create subvolumes (and root cannot prevent it!).
>>> But how can a user list these subvolumes?
>>>
>>> tux@xerus:/test/tux: btrfs subvolume create test
>>> Create subvolume './test'
>>
>> From your other posts I don't quickly get if you actually do want to
>> have this possible, or accept that it's currently like that and try to
>> do damage control by having users also remove their things again.
> 
> I want both, country AND western :-)
> 
> Without joking:
> I just want to learn more about btrfs and I have various use cases to
> handle.
> 
> Different use cases need different actions.
> 
> 
>> Actually, if you don't want this I think it's quite easily to patch your
>> kernel with one or two lines of code to disallow it.
> 
> Kernel patching is a no-go for me. My boss does not allow it. No
> discussion possible on this topic.
> 
> 
>>> tux@xerus:/test/tux: btrfs subvolume list .
>>> ERROR: can't perform the search - Operation not permitted
>>
>> Yes, because the SEARCH ioctl only allows root to directly query any of
>> the filesystem metadata from kernel memory. subvolume list uses this
>> SEARCH ioctl to find it's info.
> 
> This is the explantion why it does not work, but it does not help me. I
> still have the problem: how can a user get a list of his subvolumes? He
> may created them some time ago and forget it. He now wants to have a list
> of them.


Far to be perfect, but this could help

find / -inum 256  2>/dev/null

each subvolume has inode number 256

BR
G.Baroncelli


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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

Re: subvolume list as user?

[Ulli Horlacher]

On Sat 2017-09-16 (14:39), Hans van Kranenburg wrote:
> On 09/16/2017 11:45 AM, Ulli Horlacher wrote:
> 
> > Every user can create subvolumes (and root cannot prevent it!).
> > But how can a user list these subvolumes?
> > 
> > tux@xerus:/test/tux: btrfs subvolume create test
> > Create subvolume './test'
> 
> From your other posts I don't quickly get if you actually do want to
> have this possible, or accept that it's currently like that and try to
> do damage control by having users also remove their things again.

I want both, country AND western :-)

Without joking:
I just want to learn more about btrfs and I have various use cases to
handle.

Different use cases need different actions.


> Actually, if you don't want this I think it's quite easily to patch your
> kernel with one or two lines of code to disallow it.

Kernel patching is a no-go for me. My boss does not allow it. No
discussion possible on this topic.


> > tux@xerus:/test/tux: btrfs subvolume list .
> > ERROR: can't perform the search - Operation not permitted
> 
> Yes, because the SEARCH ioctl only allows root to directly query any of
> the filesystem metadata from kernel memory. subvolume list uses this
> SEARCH ioctl to find it's info.

This is the explantion why it does not work, but it does not help me. I
still have the problem: how can a user get a list of his subvolumes? He
may created them some time ago and forget it. He now wants to have a list
of them.

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<684fb723-4270-9589-b80b-e60ccc6da...@mendix.com>
--
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

Re: A user cannot remove his readonly snapshots?!

[Ulli Horlacher]

On Sat 2017-09-16 (13:47), Kai Krakow wrote:

> Or you do "btrfs device stats .", it shows the associated device(s).

tux@xerus:/test/tux/zz: btrfs device stats .
ERROR: getting dev info for devstats failed: Operation not permitted

Not possible for a normal user.


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20170916134748.00a7e...@jupiter.sol.kaishome.de>
--
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

Re: subvolume list as user?

[Hans van Kranenburg]

On 09/16/2017 02:39 PM, Hans van Kranenburg wrote:
> On 09/16/2017 11:45 AM, Ulli Horlacher wrote:
>> Every user can create subvolumes (and root cannot prevent it!).
>> But how can a user list these subvolumes?
>>
>> tux@xerus:/test/tux: btrfs subvolume create test
>> Create subvolume './test'
> 
> From your other posts I don't quickly get if you actually do want to
> have this possible, or accept that it's currently like that and try to
> do damage control by having users also remove their things again.
> 
> Actually, if you don't want this I think it's quite easily to patch your
> kernel with one or two lines of code to disallow it.
> 
>> tux@xerus:/test/tux: btrfs subvolume list .
>> ERROR: can't perform the search - Operation not permitted
> 
> Yes, because the SEARCH ioctl only allows root to directly query any of
> the filesystem metadata from kernel memory. subvolume list uses this
> SEARCH ioctl to find it's info.

its! Argh! D:

-- 
Hans van Kranenburg
--
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

Re: Regarding handling of file renames in Btrfs

[Hans van Kranenburg]

On 09/16/2017 02:40 PM, Martin Raiber wrote:
> Hi,
> 
> On 16.09.2017 14:27 Hans van Kranenburg wrote:
>> On 09/10/2017 01:50 AM, Rohan Kadekodi wrote:
>>> I was trying to understand how file renames are handled in Btrfs. I
>>> read the code documentation, but had a problem understanding a few
>>> things.
>>>
>>> During a file rename, btrfs_commit_transaction() is called which is
>>> because Btrfs has to commit the whole FS before storing the
>>> information related to the new renamed file.
>> Can you point to which lines of code you're looking at?
>>
>>> It has to commit the FS
>>> because a rename first does an unlink, which is not recorded in the
>>> btrfs_rename() transaction and so is not logged in the log tree. Is my
>>> understanding correct? [...]
>> Can you also point to where exactly you see this happening? I'd also
>> like to understand more about this.
>>
>> The whole mail thread following this message continues about what a
>> transaction commit is and does etc, but the above question is never
>> answered I think.
>>
>> And I think it's an interesting question. Is a rename a "heavier"
>> operation relative to other file operations?
>>
> as far as I can see it only uses the log tree in some cases where the
> log tree was already used for the file or the parent directory. The
> cases are documented here
> https://github.com/torvalds/linux/blob/master/fs/btrfs/tree-log.c#L45 .
> So rename isn't much heavier than unlink+create.

Ah. I also see that the difficult situations are about moving a file to
another directory.

So, if I just rename a file in the same directory, that's even simpler.

-- 
Hans van Kranenburg
--
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

Re: Regarding handling of file renames in Btrfs

[Martin Raiber]

Hi,

On 16.09.2017 14:27 Hans van Kranenburg wrote:
> On 09/10/2017 01:50 AM, Rohan Kadekodi wrote:
>> I was trying to understand how file renames are handled in Btrfs. I
>> read the code documentation, but had a problem understanding a few
>> things.
>>
>> During a file rename, btrfs_commit_transaction() is called which is
>> because Btrfs has to commit the whole FS before storing the
>> information related to the new renamed file.
> Can you point to which lines of code you're looking at?
>
>> It has to commit the FS
>> because a rename first does an unlink, which is not recorded in the
>> btrfs_rename() transaction and so is not logged in the log tree. Is my
>> understanding correct? [...]
> Can you also point to where exactly you see this happening? I'd also
> like to understand more about this.
>
> The whole mail thread following this message continues about what a
> transaction commit is and does etc, but the above question is never
> answered I think.
>
> And I think it's an interesting question. Is a rename a "heavier"
> operation relative to other file operations?
>
as far as I can see it only uses the log tree in some cases where the
log tree was already used for the file or the parent directory. The
cases are documented here
https://github.com/torvalds/linux/blob/master/fs/btrfs/tree-log.c#L45 .
So rename isn't much heavier than unlink+create.

Regards,
Martin Raiber

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

Re: subvolume list as user?

[Hans van Kranenburg]

On 09/16/2017 11:45 AM, Ulli Horlacher wrote:
> Every user can create subvolumes (and root cannot prevent it!).
> But how can a user list these subvolumes?
> 
> tux@xerus:/test/tux: btrfs subvolume create test
> Create subvolume './test'

>From your other posts I don't quickly get if you actually do want to
have this possible, or accept that it's currently like that and try to
do damage control by having users also remove their things again.

Actually, if you don't want this I think it's quite easily to patch your
kernel with one or two lines of code to disallow it.

> tux@xerus:/test/tux: btrfs subvolume list .
> ERROR: can't perform the search - Operation not permitted

Yes, because the SEARCH ioctl only allows root to directly query any of
the filesystem metadata from kernel memory. subvolume list uses this
SEARCH ioctl to find it's info.

-- 
Hans van Kranenburg
--
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

Re: Regarding handling of file renames in Btrfs

[Hans van Kranenburg]

Hi,

On 09/10/2017 01:50 AM, Rohan Kadekodi wrote:
> 
> I was trying to understand how file renames are handled in Btrfs. I
> read the code documentation, but had a problem understanding a few
> things.
> 
> During a file rename, btrfs_commit_transaction() is called which is
> because Btrfs has to commit the whole FS before storing the
> information related to the new renamed file.

Can you point to which lines of code you're looking at?

> It has to commit the FS
> because a rename first does an unlink, which is not recorded in the
> btrfs_rename() transaction and so is not logged in the log tree. Is my
> understanding correct? [...]

Can you also point to where exactly you see this happening? I'd also
like to understand more about this.

The whole mail thread following this message continues about what a
transaction commit is and does etc, but the above question is never
answered I think.

And I think it's an interesting question. Is a rename a "heavier"
operation relative to other file operations?

-- 
Hans van Kranenburg
--
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

Re: [PATCH] Btrfs: fix unexpected result when dio reading corrupted blocks

[Goffredo Baroncelli]

On 09/15/2017 11:06 PM, Liu Bo wrote:
> commit 4246a0b63bd8 ("block: add a bi_error field to struct bio")
> changed the logic of how dio read endio reports errors.
> 
> For single stripe dio read, %bio->bi_status reflects the error before
> verifying checksum, and now we're updating it when data block matches
> with its checksum, while in the mismatching case, %bio->bi_status is
> not updated to relfect that.
> 
> When some blocks in a file have been corrupted on disk, reading such a
> file ends up with
> 
> 1) checksum errros are reported in kernel log
> 2) read(2) returns successfully with some content being 0x01.
> 
> In order to fix it, we need to report its checksum mismatch error to
> the upper layer (dio layer in this case) as well.

I tested it, and now it works: even using O_DIRECT -EIO is returned if the file 
is corrupted.

ghigo@venice:~/btrfs/crash-o-direct/t$ ls -li
total 16384
257 -rw-r--r-- 1 root root 16777216 Sep 15 20:51 abcd
ghigo@venice:~/btrfs/crash-o-direct/t$ date
Sat Sep 16 13:56:26 CEST 2017

ghigo@venice:~/btrfs/crash-o-direct/t$ cat abcd 
cat: abcd: Input/output error
ghigo@venice:~/btrfs/crash-o-direct/t$ dmesg -T | tail -1
[Sat Sep 16 13:56:29 2017] BTRFS warning (device sdd5): csum failed root 5 ino 
257 off 0 csum 0x98f94189 expected csum 0x0ab6be80 mirror 1

ghigo@venice:~/btrfs/crash-o-direct/t$ dd if=abcd iflag=direct
dd: error reading 'abcd': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 0.000404156 s, 0.0 kB/s
ghigo@venice:~/btrfs/crash-o-direct/t$ dmesg -T | tail -1
[Sat Sep 16 13:56:41 2017] BTRFS warning (device sdd5): csum failed root 5 ino 
257 off 0 csum 0x98f94189 expected csum 0x0ab6be80 mirror 1




> 
> Signed-off-by: Liu Bo 
> Reported-by: Goffredo Baroncelli 
> cc: Goffredo Baroncelli 
> ---
>  fs/btrfs/inode.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 24bcd5c..a46799e 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -8267,11 +8267,8 @@ static void btrfs_endio_direct_read(struct bio *bio)
>   struct btrfs_io_bio *io_bio = btrfs_io_bio(bio);
>   blk_status_t err = bio->bi_status;
>  
> - if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED) {
> + if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED)
>   err = btrfs_subio_endio_read(inode, io_bio, err);
> - if (!err)
> - bio->bi_status = 0;
> - }
>  
>   unlock_extent(_I(inode)->io_tree, dip->logical_offset,
> dip->logical_offset + dip->bytes - 1);
> @@ -8279,7 +8276,7 @@ static void btrfs_endio_direct_read(struct bio *bio)
>  
>   kfree(dip);
>  
> - dio_bio->bi_status = bio->bi_status;
> + dio_bio->bi_status = err;
>   dio_end_io(dio_bio);
>  
>   if (io_bio->end_io)
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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

Re: A user cannot remove his readonly snapshots?!

[Kai Krakow]

Am Sat, 16 Sep 2017 09:36:33 +0200
schrieb Ulli Horlacher :

> On Sat 2017-09-16 (01:22), Kai Krakow wrote:
> 
> > > tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete
> > > 2017-09-15_1859.test Delete subvolume (no-commit):
> > > '/test/tux/zz/.snapshot/2017-09-15_1859.test' ERROR: cannot delete
> > > '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file
> > > system  
> > 
> > See "man mount" in section btrfs mount options: There is a mount
> > option to allow normal user to delete snapshots.  
> 
> As I wrote first: "I have mounted with option user_subvol_rm_allowed"
> 
> tux@xerus:/test/tux/zz/.snapshot: mount | grep /test
> /dev/sdd4 on /test type btrfs
> (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)
> 
> This does not help. A user cannot remove a readonly snapshot he just
> has created.

Yes, sorry, I only later discovered the other posts.


-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: A user cannot remove his readonly snapshots?!

[Marat Khalili]

On 16/09/17 13:19, Ulli Horlacher wrote:

How do I know the btrfs filesystem for a given subvolume?
Do I really have to manually test the diretory path upwards?


It was discussed recently: the answer is, unfortunately, yes, until 
someone patches df to do it for us. You can do it more or less 
efficiently by analyzing /proc/mounts .


--

With Best Regards,
Marat Khalili

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

Re: A user cannot remove his readonly snapshots?!

[Ulli Horlacher]

On Sat 2017-09-16 (10:10), Goffredo Baroncelli wrote:
> On 09/15/2017 06:37 PM, Ulli Horlacher wrote:

> > I have my btrfs filesystem mounted with option user_subvol_rm_allowed
> 
> You should change the "ro" property to false before deleting it
> 
>   btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false

Still one problem is left: 
How can I test a subvolume for the mount option user_subvol_rm_allowed?
df only works for the root subvolume:

root@xerus:/test/tux# df -T .
Filesystem Type  1K-blocks   Used Available Use% Mounted on
/dev/sdd4  btrfs  54524928 103372  52326324   1% /test

root@xerus:/test/tux# df -T zz
Filesystem Type 1K-blocks   Used Available Use% Mounted on
-  - 54524928 103372  52326324   1% /test/tux/zz

root@xerus:/test/tux# mount | grep /test
/dev/sdd4 on /test type btrfs 
(rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

How do I know the btrfs filesystem for a given subvolume?
Do I really have to manually test the diretory path upwards?


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:
--
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

subvolume list as user?

[Ulli Horlacher]

Every user can create subvolumes (and root cannot prevent it!).
But how can a user list these subvolumes?

tux@xerus:/test/tux: btrfs subvolume create test
Create subvolume './test'

tux@xerus:/test/tux: btrfs subvolume list .
ERROR: can't perform the search - Operation not permitted


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de
REF:<20170916094504.gl32...@rus.uni-stuttgart.de>
--
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

Re: A user cannot remove his readonly snapshots?!

[Ulli Horlacher]

On Sat 2017-09-16 (11:04), Goffredo Baroncelli wrote:

> In the past I proposed to allow an ordinary user to remove an *empty* 
> subvolume with a simple rmdir (if he has the permissions). This would solve 
> this kind of problem.
> or to relax the check around "btrfs sub del", so an user can remove an 
> _empty_ subvolume

This would help a lot!
Where can I sign this petition? :-)

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<2d343791-7b32-bd53-a03d-a5b26465d...@libero.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

Re: A user cannot remove his readonly snapshots?!

[Peter Grandi]

[ ... ]

> I can delete normal subvolumes but not the readonly snapshots:

It is because of ordinary permissions for both subvolumes and
snapshots:

  tree$  btrfs sub create /fs/sda7/sub
  Create subvolume '/fs/sda7/sub'

  tree$  chmod a-w /fs/sda7/sub
  tree$  btrfs sub del /fs/sda7/sub
  Delete subvolume (no-commit): '/fs/sda7/sub'
  ERROR: cannot delete '/fs/sda7/sub': Permission denied

  tree$  chmod u+w /fs/sda7/sub
  tree$  btrfs sub del /fs/sda7/sub
  Delete subvolume (no-commit): '/fs/sda7/sub'

It is however possible to remove an ordinary read-only
directory, *as long as its parent directory is not read-only
too*:

  tree$  mkdir /fs/sda7/sub
  tree$  chmod a-w /fs/sda7/sub
  tree$  rmdir /fs/sda7/sub; echo $?
  0

IIRC this came up before, and the reason for the difference is
that a subvolume root directory is "special" because its '..'
entry points to itself (inode 256), that is if it is read-only
its parent directory (itself) then is read-only too.
--
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

Re: A user cannot remove his readonly snapshots?!

[Goffredo Baroncelli]

On 09/16/2017 01:22 AM, Kai Krakow wrote:
> Am Sat, 16 Sep 2017 00:02:01 +0200
> schrieb Ulli Horlacher :
> 
>> On Fri 2017-09-15 (23:44), Ulli Horlacher wrote:
[...]
> 
> See "man mount" in section btrfs mount options: There is a mount option
> to allow normal user to delete snapshots. But this is said to has
> security implication I cannot currently tell. Maybe someone else knows.

"btrfs sub del" removes a subvolume independently by its contents: it doesn't 
check the subvolume files/directories and their permission/ownership. 

This is different from a "rm -rf", which (e.g.) can't delete a directory owned 
by a different user with files

ghigo@venice:/tmp$ mkdir d
ghigo@venice:/tmp$ mkdir d/d
ghigo@venice:/tmp$ touch d/d/f
ghigo@venice:/tmp$ sudo chown nobody d/d
ghigo@venice:/tmp$ rm -rf d
rm: cannot remove 'd/d/f': Permission denied

In the past I proposed to allow an ordinary user to remove an *empty* subvolume 
with a simple rmdir (if he has the permissions). This would solve this kind of 
problem.

https://www.spinics.net/lists/linux-btrfs/msg06499.html

or to relax the check around "btrfs sub del", so an user can remove an _empty_ 
subvolume

https://www.spinics.net/lists/linux-btrfs/msg06522.html

> 
> 
BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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

Re: A user cannot remove his readonly snapshots?!

[Ulli Horlacher]

On Sat 2017-09-16 (10:10), Goffredo Baroncelli wrote:

> > tux@xerus: btrfs subvolume snapshot -r /test/tux/zz 
> > /test/tux/zz/.snapshot/2017-09-15_1824.test
> > tux@xerus: btrfs subvolume delete 
> > /test/tux/zz/.snapshot/2017-09-15_1824.test
> > Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
> > ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': 
> > Read-only file system
> > 
> > root can delete this snapshot, but not the user. Why?
> 
> You should change the "ro" property to false before deleting it
> 
>   btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false

tux@xerus: btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro 
false
tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'

That's it! It works (now)! Great! Thanks!

Up to now I was thinking about a sudo solution, but this is not necessary
any more. Less complex solutions are always better :-)

I *love* this mailing list :-)

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:
--
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

Re: A user cannot remove his readonly snapshots?!

[Goffredo Baroncelli]

On 09/15/2017 06:37 PM, Ulli Horlacher wrote:
> I have my btrfs filesystem mounted with option user_subvol_rm_allowed
> 
> tux@xerus: btrfs --version
> btrfs-progs v4.4
> 
> tux@xerus: uname -a
> Linux xerus 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> tux@xerus: id
> uid=1000(tux) gid=100(users) groups=100(users)
> 
> tux@xerus: btrfs subvolume snapshot -r /test/tux/zz 
> /test/tux/zz/.snapshot/2017-09-15_1824.test
> tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test
> Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
> ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': Read-only 
> file system
> 
> root can delete this snapshot, but not the user. Why?

You should change the "ro" property to false before deleting it

btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false


BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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

Re: A user cannot remove his readonly snapshots?!

[Ulli Horlacher]

On Sat 2017-09-16 (01:22), Kai Krakow wrote:

> > tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete
> > 2017-09-15_1859.test Delete subvolume (no-commit):
> > '/test/tux/zz/.snapshot/2017-09-15_1859.test' ERROR: cannot delete
> > '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file system
> 
> See "man mount" in section btrfs mount options: There is a mount option
> to allow normal user to delete snapshots.

As I wrote first: "I have mounted with option user_subvol_rm_allowed"

tux@xerus:/test/tux/zz/.snapshot: mount | grep /test
/dev/sdd4 on /test type btrfs 
(rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

This does not help. A user cannot remove a readonly snapshot he just has
created.


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20170916012248.0870f...@jupiter.sol.kaishome.de>
--
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