On Tue, Sep 24, 2019 at 10:15:13AM -0700, Omar Sandoval wrote:

On Thu, Sep 19, 2019 at 05:44:12PM +0200, Jann Horn wrote:

quoted

On Thu, Sep 19, 2019 at 8:54 AM Omar Sandoval [off-list ref] wrote:

quoted

Btrfs can transparently compress data written by the user. However, we'd
like to add an interface to write pre-compressed data directly to the
filesystem. This adds support for so-called "encoded writes" via
pwritev2().

A new RWF_ENCODED flags indicates that a write is "encoded". If this
flag is set, iov[0].iov_base points to a struct encoded_iov which
contains metadata about the write: namely, the compression algorithm and
the unencoded (i.e., decompressed) length of the extent. iov[0].iov_len
must be set to sizeof(struct encoded_iov), which can be used to extend
the interface in the future. The remaining iovecs contain the encoded
extent.

A similar interface for reading encoded data can be added to preadv2()
in the future.

Filesystems must indicate that they support encoded writes by setting
FMODE_ENCODED_IO in ->file_open().

[...]

quoted

+int import_encoded_write(struct kiocb *iocb, struct encoded_iov *encoded,
+                        struct iov_iter *from)
+{
+       if (iov_iter_single_seg_count(from) != sizeof(*encoded))
+               return -EINVAL;
+       if (copy_from_iter(encoded, sizeof(*encoded), from) != sizeof(*encoded))
+               return -EFAULT;
+       if (encoded->compression == ENCODED_IOV_COMPRESSION_NONE &&
+           encoded->encryption == ENCODED_IOV_ENCRYPTION_NONE) {
+               iocb->ki_flags &= ~IOCB_ENCODED;
+               return 0;
+       }
+       if (encoded->compression > ENCODED_IOV_COMPRESSION_TYPES ||
+           encoded->encryption > ENCODED_IOV_ENCRYPTION_TYPES)
+               return -EINVAL;
+       if (!capable(CAP_SYS_ADMIN))
+               return -EPERM;

How does this capable() check interact with io_uring? Without having
looked at this in detail, I suspect that when an encoded write is
requested through io_uring, the capable() check might be executed on
something like a workqueue worker thread, which is probably running
with a full capability set.

I discussed this more with Jens. You're right, per-IO permission checks
aren't going to work. In fully-polled mode, we never get an opportunity
to check capabilities in right context. So, this will probably require a
new open flag.

Actually, file_ns_capable() accomplishes the same thing without a new
open flag. Changing the capable() check to file_ns_capable() in
init_user_ns should be enough.