On Thu, Nov 22, 2007 at 07:56:20PM +, Alan Cox wrote:
> > probably principle of least privilege; the location on physical media
> > for a file is clearly something internal to the OS, and non-trusted
> > users normally don't have any business knowing that.
>
> FIBMAP isn't correctly locked ag
> probably principle of least privilege; the location on physical media
> for a file is clearly something internal to the OS, and non-trusted
> users normally don't have any business knowing that.
FIBMAP isn't correctly locked against misuse, and that requires FIBMAP is
safe against truncate and
On Thu, 22 Nov 2007 19:17:14 +0100
Jan Kara <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
> special capabilities so we are inconsistent here too...
> Would
Original thread btw:
http://www.ussg.indiana.edu/hypermail/linux/kernel/9907.0/0132.html
OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read th
On Thu, Nov 22, 2007 at 07:17:14PM +0100, Jan Kara wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
> special capabilities so we are inconsistent here too...
> Would anyone mind if
On Thu, 22 Nov 2007 19:17:14 +0100
Jan Kara <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without
> any special capabilities so we are inconsistent here too...
> Would
Hi,
I guess subject says it all - why is FIBMAP ioctl restricted only to
root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
special capabilities so we are inconsistent here too...
Would anyone mind if the check is removed?
7 matches
Mail list logo