lkml.org 
[lkml]   [2018]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]
    Date
    Amir Goldstein <amir73il@gmail.com> wrote:

    > Reject O_NON_RECURSIVE without O_CLONE_MOUNT?

    Yes, I should add that.

    > I am not sure what are the consequences of opening O_PATH with old kernel
    > and getting an open file, can't think of anything bad.
    > Can the same be claimed for O_PATH|O_CLONE_MOUNT?

    Yes, actually, there can be consequences. Some files have side effects.
    Think open("/dev/foobar", O_PATH).

    > Wouldn't it be better to apply the O_TMPFILE kludge to the new
    > open flag, so that apps can check if O_CLONE_MOUNT feature is supported
    > by kernel?

    Ugh. The problem is that the O_TMPFILE kludge can't be done because O_PATH
    currently just masks off any bits it's not interested in rather than giving an
    error.

    Even the O_TMPFILE kludge doesn't protect you against someone having set
    random unassigned bits when testing on a kernel that didn't support it.

    And this bit:

    /*
    * Clear out all open flags we don't know about so that we don't report
    * them in fcntl(F_GETFD) or similar interfaces.
    */
    flags &= VALID_OPEN_FLAGS;

    is just plain wrong. Effectively, it allows userspace to set random reserved
    bits without consequences. It should give an error instead.

    Probably we should really replace open() and openat() both before we can
    allocate any further open flags.

    </grumble>

    David

    \
     
     \ /
      Last update: 2018-06-01 10:44    [W:5.056 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site