lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 10 Dec 2021 22:53:00 +0300 (MSK)
From:   Roman Anufriev <>
To:     Andreas Dilger <>
cc:     "Theodore Y. Ts'o" <tytso@....EDU>,,
        linux-ext4 <>, Jan Kara <>,
        Wang Shilong <>,
        Dmitry Monakhov <>,
        "Darrick J. Wong" <>
Subject: Re: [PATCH] ext4: compare inode's i_projid with EXT4_DEF_PROJID
 rather than check EXT4_INODE_PROJINHERIT flag

On Thu, 9 Dec 2021, Andreas Dilger wrote:

> On Dec 7, 2021, at 12:34 PM, Theodore Y. Ts'o <tytso@....EDU> wrote:
>> On Tue, Dec 07, 2021 at 05:05:19PM +0300, Roman Anufriev wrote:
>>>> Commit 7ddf79a10395 ("ext4: only set project inherit bit for directory")
>>>> removes EXT4_INODE_PROJINHERIT flag from regular files. This makes
>>>> ext4_statfs() output incorrect (function does not apply quota limits
>>>> on used/available space, etc) when called on dentry of regular file
>>>> with project quota enabled.
>> Under what circumstance is userspace trying to call statfs on a file
>> descriptor?
> Who knows what users do?  Calling statfs() on a regular file works fine
> (returns stats for the filesystem), so I don't see why it wouldn't be
> consistent when calling statfs() on a file with projid set?

This is exactly my reasoning for this patch.

> Darrick, how does XFS handle this case?  I think it makes sense to be
> consistent with that implementation, since that was the main reason to
> remove PROJINHERIT from regular files in the first place.
>> Removing the test for EXT4_INODE_PROJINHERIT will cause
>> incorrect/misleading results being returned in the case where we have
>> a directory where a directory hierarchy is using project id's, but
>> which is *not* using PROJINHERIT.
> One alternative would be to check the PROJINHERIT status of the parent
> directory after calling statfs() on the regular file?  That should
> keep the semantics for PROJINHERIT the same, but avoid inconsistent
> results if called on a regular file:
> -	if (ext4_test_inode_flag(dentry->d_inode, EXT4_INODE_PROJINHERIT) &&
> +	if (ext4_test_inode_flag(S_ISDIR(dentry->d_inode) ? dentry->d_inode :
> +			   dentry->d_parent->d_inode, EXT4_INODE_PROJINHERIT) &&
> 	    sb_has_quota_limits_enabled(sb, PRJQUOTA))
> 		ext4_statfs_project(sb, EXT4_I(dentry->d_inode)->i_projid, buf);
> #endif
> Roman, does that work for you?

Yes, it was actually the first thing that came to my mind. But later I
realised, that there may be some pitfalls and it would probably make more
sense to check inode's own project id and report stats based on that. As
I thought that we check presense of EXT4_INODE_PROJINHERIT flag only to
make sure that this inode belongs to some project.


Powered by blists - more mailing lists