[CC the xfs list. Kees - I shouldn't have to remind you to do this. ]
On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote:
> Hi,
>
> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add
> capability check to free eofblocks ioctl") is a security fix that was
> never sent to -stable? From what I can see, it was introduced in 3.8
> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add
> XFS_IOC_FREE_EOFBLOCKS ioctl").
>
> I don't see this in the 3.8.y tree. Should it be added there and newer?
Well, it's not really a security problem at all, given that it only
affects speculative preallocation beyond EOF. i.e. it affects
filesystem metadata that does not yet index any user data.
Indeed, the kernel already does exactly what this ioctl does every 5
minutes without user intervention. i.e. it's simply a maintenance
task we need to execute periodically or on demand as a result of
other events (e.g. from a userspace daemon that is listen to quota
exhaustion messages).
So apart from allowing a user to burn some CPU with the ioctl doing
nothing but scanning, there's little in way of a security problem
being exposed on kernels prior to 3.12 here.
The reason for the cap check? Turning off this ioctl in containers
restricted by user name spaces. i.e. new functionality added to XFS
in 3.12 introduced curiously vague and difficult to explain new
inode access restrictions, so we took the "be safe by default" route
and only allowed the init namespace access to the ioctl....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
