Thread (30 messages) 30 messages, 3 authors, 2020-08-25

Re: [PATCH v5 2/9] fs: add O_ALLOW_ENCODED open flag

From: Omar Sandoval <osandov@osandov.com>
Date: 2020-08-24 21:11:22
Also in: linux-btrfs, linux-fsdevel

On Mon, Aug 24, 2020 at 02:28:39PM -0400, Josef Bacik wrote:
On 8/21/20 3:38 AM, Omar Sandoval wrote:
quoted
From: Omar Sandoval <redacted>

The upcoming RWF_ENCODED operation introduces some security concerns:

1. Compressed writes will pass arbitrary data to decompression
    algorithms in the kernel.
2. Compressed reads can leak truncated/hole punched data.

Therefore, we need to require privilege for RWF_ENCODED. It's not
possible to do the permissions checks at the time of the read or write
because, e.g., io_uring submits IO from a worker thread. So, add an open
flag which requires CAP_SYS_ADMIN. It can also be set and cleared with
fcntl(). The flag is not cleared in any way on fork or exec; it should
probably be used with O_CLOEXEC in most cases.

Note that the usual issue that unknown open flags are ignored doesn't
really matter for O_ALLOW_ENCODED; if the kernel doesn't support
O_ALLOW_ENCODED, then it doesn't support RWF_ENCODED, either.
It seemed like you agreed to require O_CLOEXEC to be set when using
O_ALLOW_ENCODED in your last go around, what happened to that?  I know I'd
feel better if we had that requirement, and if we aren't I'd like to know
why we can't.  Thanks,

Josef
Yup I was still on the fence about it since it's a bit of an awkward
requirement, but I'm convinced now that we might as well be safe and
require it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help