On Tue, Feb 25, 2020 at 4:36 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > Hmm, maybe let's back up a step here. What's the purpose of being able > to set quota_on privileges on a file? Is it so that sysadmins can > designate a particular file as a "quota" file and thereby prevent the > kernel from being tricked into loading some other file as the quota data > file? Yes. > I ask this because AFAICT in ext4, the "usrjquota=<path>" mount options > are for the old quota system wherein quotas are files that are managed > separately from the filesystem. > > The new ext4 quota system links the quota inode pointers only from the > superblock, and it calls dquot_load_quota_inode, which doesn't seem to > have a security callout. Seeing as there's no user-visible file for new > style quotas, I don't see why you'd need a selinux hook either. > > I guess it could be generally useful to be able to be able to apply the > same quota_on labels to root directories of filesystems that have new > style quotas that one can apply to quota files on fses with old style > quotas... but (a) I don't see that being the case right now, and (b) if > you're trying to /add/ that functionality then yes it ought to be in > fs/quota/... and yes xfs will have to play catch up once it's there. > > Is there already a precedent for setting quota_on labels to the root > dir? It's entirely possible that I'm simply unaware of what's going on > in fs/quota/ because xfs mostly does its own things wrt quota. Ok, in that case I'd say we don't need the hook to be called at all in the cases where the quota inode is private to the superblock and not directly exposed to userspace. So no change required to xfs or fs/quota and we can skip/ignore the test when not using usrquota=...
