lkml.org 
[lkml]   [2018]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 0/3] namei: implement various lookup restriction AT_* flags
    On 2018-10-09, Aleksa Sarai <cyphar@cyphar.com> wrote:
    > The need for some sort of control over VFS's path resolution (to avoid
    > malicious paths resulting in inadvertent breakouts) has been a very
    > long-standing desire of many userspace applications. This patchset is a
    > revival of Al Viro's old AT_NO_JUMPS[1,2] patchset (which was a variant
    > of David Drysdale's O_BENEATH patchset[3] which was a spin-off of the
    > Capsicum project[4]) with a few additions and changes made based on the
    > previous discussion within [5] as well as others I felt were useful.

    I've been thinking about this problem a little more (from the UX side of
    things) and I have a feeling that adding 5 different O_* flags related
    to resolution -- rather than properties related to opening the file --
    might be less than ideal (even though, as discussed in previous threads,
    there is a need for these flags and for them to be separated).

    There is *some* precedence for this with O_PATH[**] changing fairly
    large semantics of openat(2) but there are some things about O_PATH
    which I think could be improved.

    What if we had a resolveat(2) which acted like openat(..., O_PATH) *but*
    it allowed us to have new flags and to separate the scoping flags from
    the (fairly limited) space of O_* flags. Then O_PATH could effectively
    just be a legacy way of doing resolveat(2) -- with only O_CLOEXEC,
    O_DIRECTORY, and O_NOFOLLOW support.

    And the main things we could add would be:

    * These resolution flags, with only support available from
    resolveat(2) for the moment. The idea would be that AT_EMPTY_PATH
    would be the recommended way to make use of this.

    * Support for RESOLVE_{NOPERM,RDONLY,WRONLY,RDWR} (which after some
    discussions with Eric last year might be necessary in order to make
    /proc/$pid/fd/$fd re-opening of O_PATH descriptors safer -- which is
    something that we use in both runc and LXC).

    Is this idea palatable, or was this something considered during the
    development of O_PATH and someone had an argument why augmenting O_PATH
    is better than a new syscall?

    [**] And while writing this paragraph I noticed that I didn't update the
    O_PATH "flag whitelist" to allow the scoping flags to affect it. I
    will include a fix for this in v4 (I must've lost it in an early
    rebase before I sent v1).

    --
    Aleksa Sarai
    Senior Software Engineer (Containers)
    SUSE Linux GmbH
    <https://www.cyphar.com/>
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2018-10-17 17:24    [W:3.712 / U:0.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site