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
> 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
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
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?
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 anyone
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?
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 the
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 the
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 anyone
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, 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 against
14 matches
Mail list logo
