linux-kernel - Re: [PATCH v3 0/2] quota: Add mountpath based quota support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20210512125310.m3b4ralhwsdocpyb@wittgenstein>
Date:   Wed, 12 May 2021 14:53:10 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Sascha Hauer <s.hauer@...gutronix.de>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org, Christoph Hellwig <hch@...radead.org>,
        kernel@...gutronix.de, Jan Kara <jack@...e.com>,
        Richard Weinberger <richard@....at>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v3 0/2] quota: Add mountpath based quota support

On Wed, May 12, 2021 at 01:01:49PM +0200, Jan Kara wrote:
> Added a few more CCs.
> 
> On Tue 16-03-21 12:29:16, Jan Kara wrote:
> > On Thu 04-03-21 13:35:38, Sascha Hauer wrote:
> > > Current quotactl syscall uses a path to a block device to specify the
> > > filesystem to work on which makes it unsuitable for filesystems that
> > > do not have a block device. This series adds a new syscall quotactl_path()
> > > which replaces the path to the block device with a mountpath, but otherwise
> > > behaves like original quotactl.
> > > 
> > > This is done to add quota support to UBIFS. UBIFS quota support has been
> > > posted several times with different approaches to put the mountpath into
> > > the existing quotactl() syscall until it has been suggested to make it a
> > > new syscall instead, so here it is.
> > > 
> > > I'm not posting the full UBIFS quota series here as it remains unchanged
> > > and I'd like to get feedback to the new syscall first. For those interested
> > > the most recent series can be found here: https://lwn.net/Articles/810463/
> > 
> > Thanks. I've merged the two patches into my tree and will push them to
> > Linus for the next merge window.
> 
> So there are some people at LWN whining that quotactl_path() has no dirfd
> and flags arguments for specifying the target. Somewhat late in the game
> but since there's no major release with the syscall and no userspace using
> it, I think we could still change that. What do you think? What they
> suggest does make some sense. But then, rather then supporting API for
> million-and-one ways in which I may wish to lookup a fs object, won't it be
> better to just pass 'fd' in the new syscall (it may well be just O_PATH fd
> AFAICT) and be done with that?

I think adding a dirfd argument makes a lot of sense (Unless there are
some restrictions around quotas I'm misunderstanding.).

If I may: in general, I think we should aim to not add additional system
calls that operate on paths only. Purely path-based apis tend to be the
source of security issues especially when scoped lookups are really
important which given the ubiquity of sandboxing solutions nowadays is
quite often actually.
For example, when openat2() landed it gave such a boost in lookup
capabilities that I switched some libraries over to only ever do scoped
lookups, i.e. I decide on a starting point that gets opened path-based
and then explicitly express how I want that lookup to proceed ultimately
opening the final path component on which I want to perform operations.
Combined with the mount API almost everything can be done purely fd
based.

In addition to that dirfd-scopable system calls allow for a much nicer
api experience when programming in userspace.

Christian