All of lore.kernel.org
 help / color / mirror / Atom feed
* security.capability xattr missing after btrfs send/receive
@ 2015-02-01 12:13 Jan Andres
  2015-02-01 17:15 ` Juan Orti
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Andres @ 2015-02-01 12:13 UTC (permalink / raw)
  To: linux-btrfs

I found that the security.capability xattr gets lost when cloning a
subvolume via btrfs send | btrfs receive. This is easy to reproduce
(currently on 3.19.0-rc6, x86_64, with btrfs-progs 3.18.1):

Have two btrfs file systems, "/fs1" and "/fs2".

# btrfs sub create /fs1/test
# touch /fs1/test/foo
# setcap cap_net_admin+ep /fs1/test/foo
# getcap /fs1/test/foo
/fs1/test/foo = cap_net_admin+ep
# btrfs prop set /fs1/test ro true
# btrfs send /fs1/test | btrfs receive /fs2
# getcap /fs2/test/foo
[reports nothing]


The cause of the problem seems to be that BTRFS_SEND_C_SET_XATTR comes
before BTRFS_SEND_C_CHMOD in the send stream, so that the receiving end
will first correctly restore all the xattrs of the file, and after that,
perform an lchown() which will cause the kernel to reset the
file's capabilities.

I don't know how to fix this correctly (especially in the case of
incremental sends), so I don't have a patch, but figured it might be
useful to share what I found.

Regards,
Jan

-- 
Jan Andres <jandres@gmx.net>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: security.capability xattr missing after btrfs send/receive
  2015-02-01 12:13 security.capability xattr missing after btrfs send/receive Jan Andres
@ 2015-02-01 17:15 ` Juan Orti
  2015-02-01 17:57   ` Chris Murphy
  0 siblings, 1 reply; 3+ messages in thread
From: Juan Orti @ 2015-02-01 17:15 UTC (permalink / raw)
  To: Jan Andres; +Cc: linux-btrfs

El dom, 01-02-2015 a las 13:13 +0100, Jan Andres escribió:
> I found that the security.capability xattr gets lost when cloning a
> subvolume via btrfs send | btrfs receive. This is easy to reproduce
> (currently on 3.19.0-rc6, x86_64, with btrfs-progs 3.18.1):
> 
> Have two btrfs file systems, "/fs1" and "/fs2".
> 
> # btrfs sub create /fs1/test
> # touch /fs1/test/foo
> # setcap cap_net_admin+ep /fs1/test/foo
> # getcap /fs1/test/foo
> /fs1/test/foo = cap_net_admin+ep
> # btrfs prop set /fs1/test ro true
> # btrfs send /fs1/test | btrfs receive /fs2
> # getcap /fs2/test/foo
> [reports nothing]
> 
> 
> The cause of the problem seems to be that BTRFS_SEND_C_SET_XATTR comes
> before BTRFS_SEND_C_CHMOD in the send stream, so that the receiving end
> will first correctly restore all the xattrs of the file, and after that,
> perform an lchown() which will cause the kernel to reset the
> file's capabilities.
> 
> I don't know how to fix this correctly (especially in the case of
> incremental sends), so I don't have a patch, but figured it might be
> useful to share what I found.

https://bugzilla.kernel.org/show_bug.cgi?id=68891

-- 
Juan Orti
https://miceliux.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: security.capability xattr missing after btrfs send/receive
  2015-02-01 17:15 ` Juan Orti
@ 2015-02-01 17:57   ` Chris Murphy
  0 siblings, 0 replies; 3+ messages in thread
From: Chris Murphy @ 2015-02-01 17:57 UTC (permalink / raw)
  Cc: Btrfs BTRFS

Looks like security.capabilities also has tripped up tar.
https://bugzilla.redhat.com/show_bug.cgi?id=771927

There's a suggestion that security.capabilities are "non standard
attributes"? Also, comment 28 is interesting. Anyway it seems a big
messy to support them in any case.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-02-01 17:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-01 12:13 security.capability xattr missing after btrfs send/receive Jan Andres
2015-02-01 17:15 ` Juan Orti
2015-02-01 17:57   ` Chris Murphy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.