On Thu, Jun 20, 2013 at 03:45:43PM -0700, Eric W. Biederman wrote:
> I have a question about the project quota. Is it intended that any
> user can set an project quota on any file? Unless I am misreading
> xfs_ioctl_setattr that is what it allows.
Only on files they own. There is this check in xfs_ioctl_setattr():
/*
* CAP_FOWNER overrides the following restrictions:
*
* The user ID of the calling process must be equal
* to the file owner ID, except in cases where the
* CAP_FSETID capability is applicable.
*/
if (current_fsuid() != ip->i_d.di_uid && !capable(CAP_FOWNER)) {
code = XFS_ERROR(EPERM);
goto error_return;
}
> My narrow focus concern on this is that if the user is in a user
> namespace these ids need to be mapped before we look at them or else
> we will do the wrong thing.
The user IDs need to be mapped, yes, but do we want to map project
IDs? Project IDs are the property of the underlying filesystem, not
that of a user namespace. Users can change what project their files
are associated with, but they cannot change their UID or GID....
I can see reasons for wanting the same project quota id to be shared
across multiple namespaces. e.g. setting up a directory tree quota
for a specific set of namespaces where you don't care about
individual namespace space usage but you want the group as a whole
to be limited.
Indeed, the use of project quotas as an external management tool for
limiting the filesystem space a namespace container can actually
consume makes an interesting argument for preventing access to
project quotas from any namespace other than the init_user_ns.
So, rather than saying "it must be mapped", how about we start by
thinking about how we wnt project quotas to be used in containerised
namespace configurations and work from there....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
