linux-kernel - Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Oct 2007 15:40:35 -0700
From:	Jason Uhlenkott <jasonuhl@...onuhl.org>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

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.

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/