linux-kernel - Re: statx(2) API and documentation

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: <20181018074101.GJ23493@quack2.suse.cz>
Date:   Thu, 18 Oct 2018 09:41:01 +0200
From:   Jan Kara <jack@...e.cz>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Miklos Szeredi <miklos@...redi.hu>,
        Andreas Dilger <adilger@...ger.ca>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
        David Howells <dhowells@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Re: statx(2) API and documentation

On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
> On Wed, Oct 17, 2018 at 10:12 PM Miklos Szeredi <miklos@...redi.hu> wrote:
> 
> > >> - STATX_ALL definition is unclear, can this change, or is it fixed?
> > >> If it's the former, than that's a backward compatibility nightmare.
> > >> If it's the latter, then what's the point?
> > >
> > > The value can change over time.  It is intended to reflect the current
> > > state of affairs at the time the userspace program and kernel are compiled.
> > > The value sent from userspace lets the kernel know what fields are in
> > > the userspace struct, so it doesn't try to set fields that aren't there.
> >
> > What's the point of a userspace program specifying STATX_ALL?  Without
> > a way to programmatically query the interface definition it's useless:
> > there's no way to guess which mask bit corresponds to which field, and
> > what that field represents.
> >
> > And there will be programs out there which specify STATX_ALL without
> > considering that in the future it may become slower as it is now due
> > to a recompile.
> >
> > So what's the point exactly?
> >
> > > The value in the kernel allows masking off new fields from userspace that
> > > it doesn't understand.
> >
> > Okay, but that has nothing to do with the UAPI.  Even as an internal
> > flag we should be careful, as it might grow uses which can have
> > similar issues as the userspace one above.
> >
> 
> FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to
> add new flags and did not want to change the UAPI _ALL_ constants.
> This is how we plan to solve it:
> https://github.com/amir73il/linux/commit/8c2b1acadb88ee4505ccc8bfdc665863111fb4cc

Yeah, after fanotify experience I find foo_ALL constants useless if not
dangerous for userspace.  Kernel internal constants like this are IMO
useful.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR