linux-ext4 - Re: ext4 and project quotas bugs

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 29 Apr 2020 12:42:01 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Jan Kara <jack@...e.cz>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Francois <rigault.francois@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: ext4 and project quotas bugs

On Tue, Apr 28, 2020 at 06:48:24PM +0200, Jan Kara wrote:
> On Tue 28-04-20 08:53:51, Darrick J. Wong wrote:
> > On Tue, Apr 28, 2020 at 05:32:28PM +0200, Jan Kara wrote:
> > > > dd if=/dev/zero of=someoutput oflag=append
> > > > dd: failed to open 'someoutput': Invalid argument
> > > 
> > > Yes, that's a bug that should be fixed. Thanks for reporting this! -1 means
> > > 'this id is not expressible in current user namespace' and some code gets
> > > confused along the way. We should refuse to set project -1 for a file...
> > 
> > Awkward part: projid 4294967295 is allowed on XFS (at least by the
> > kernel), though the xfs quota tools do not permit that.
> 
> Are you OK with just refusing to set projid 4294967295 for everybody? Or
> should we just not try to translate project IDs through user namespaces?
> Because XFS does not seem to translate them while ext4 does... What a mess.

We do not translate project IDs through user names space because
they are not usable as a mappable id. Project IDs are only used for
customised aggregation of space accounting, unlike UIDs and GIDS
that are used primarily for access control. IOWs, PRIDs are
fundamentally different to UIDs and GIDs.

Project IDs were already being used in the init namespace for
directory quotas to limit containers using bind mounts on a host
filesystem to an amount of disk space less than the entire hosting
filesystem.  And once you use PRIDs in the init namespace, they
cannot be used by users in other user namespaces, regardless of
whether they are mappable or not.

Essentially, the project ID mapping stuff was implemented by someone
who didn't understand what project IDs were or how project IDs were
being used, and then refused to listen to the people who knew these
things and wanted them to drop the PRID mapping stuff.  And then
Linus pulled their tree containing all the uid/gid/prid mapping code
without warning and we've been stuck with this shit ever since.

Hence in XFS we simply do not allow project IDs to be manipulated
outside of the init user namespace, and so mapping them is
irrelevant because users in confined namespaces cannot usefully
interact with them in any way.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com