lkml.org 
[lkml]   [2007]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP
    Jason Uhlenkott wrote:
    > On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote:
    >> Jason Uhlenkott wrote:
    >>> Additionally, ext3_bmap() has this to say about it:
    >>>
    >>> if (EXT3_I(inode)->i_state & EXT3_STATE_JDATA) {
    >>> /*
    >>> * This is a REALLY heavyweight approach, but the use of
    >>> * bmap on dirty files is expected to be extremely rare:
    >>> * only if we run lilo or swapon on a freshly made file
    >>> * do we expect this to happen.
    >>> *
    >>> * (bmap requires CAP_SYS_RAWIO so this does not
    >>> * represent an unprivileged user DOS attack --- we'd be
    >>> * in trouble if mortal users could trigger this path at
    >>> * will.)
    >> Hmm. I don't know what the right approach to this is. This seems to be
    >> the same situation as the delayed allocation problem, no?
    >
    > Yup.
    >
    >> What if we just returned 0? Tools like lilo are already doing sync(),
    >> would that cause the journal to get flushed explicitly anyway?
    >
    > Not sure, but I'd be pretty nervous about breaking any existing users
    > which aren't explicitly syncing.

    True. We can probably get away with an implicit flush when
    CAP_SYS_RAWIO is set, but that's pretty gross :(

    >
    > Are you envisioning users who want to see where their data is landing
    > for performance reasons? It seems like such users are going to have
    > sufficiently different desires from existing FIBMAP users (who need to
    > know where everything is because they intend to fiddle with the raw
    > device) that a different interface might be warranted.

    A little of both ;)

    We could introduce a new API, though either way, the same fundamental
    problems apply wrt auditing.

    I see three reasons that new APIs are warranted:

    a) to deal with block numbers > 2^31 --> FIBMAP64
    b) to have a path where no syncing is required due to worries about user
    DoS (delayed allocation / data in journal).
    c) possibly some way to FIBMAP a range so that userspace doesn't need to
    syscall for each block, something like how mincore() does it?

    I have a patchset ready that I'll send out shortly that introduces
    FIBMAP64. The last patch in that set drops the CAP_SYS_RAWIO, but it's
    probably not what we want given DoS case. I'd like to send it out
    anyway to get some comments on some of the sanity checks and locking I'm
    adding.

    Handling (c) above is just extra sugar and isn't something I'm too
    worried about implementing.

    Mike Waychison
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-27 00:57    [W:0.030 / U:89.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site