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]
Date:   Tue, 03 Mar 2020 14:43:44 -0500
From:   Jeff Layton <jlayton@...nel.org>
To:     Jens Axboe <axboe@...nel.dk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jann Horn <jannh@...gle.com>
Cc:     Miklos Szeredi <miklos@...redi.hu>, Karel Zak <kzak@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Ian Kent <raven@...maw.net>,
        Christian Brauner <christian.brauner@...ntu.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Steven Whitehouse <swhiteho@...hat.com>,
        Miklos Szeredi <mszeredi@...hat.com>,
        viro <viro@...iv.linux.org.uk>,
        Christian Brauner <christian@...uner.io>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications
 [ver #17]

On Tue, 2020-03-03 at 12:23 -0700, Jens Axboe wrote:
> On 3/3/20 12:02 PM, Jeff Layton wrote:
> > Basically, all you'd need to do is keep a pointer to struct file in the
> > internal state for the chain. Then, allow userland to specify some magic
> > fd value for subsequent chained operations that says to use that instead
> > of consulting the fdtable. Maybe use -4096 (-MAX_ERRNO - 1)?
> 
> BTW, I think we need two magics here. One that says "result from
> previous is fd for next", and one that says "fd from previous is fd for
> next". The former allows inheritance from open -> read, the latter from
> read -> write.
> 

Do we? I suspect that in almost all of the cases, all we'd care about is
the last open. Also if you have unrelated operations in there you still
have to chain the fd through somehow to the next op which is a bit hard
to do with that scheme.

I'd just have a single magic carveout that means "use the result of last
open call done in this chain". If you do a second open (or pipe, or...),
then that would put the old struct file pointer and drop a new one in
there.

If we really do want to enable multiple opens in a single chain though,
then we might want to rethink this and consider some sort of slot table
for storing open fds.

-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists