linux-kernel - Re: srvfs: file system for posting open file descriptors into fs namespace

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:   Fri, 7 Aug 2020 17:23:05 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: srvfs: file system for posting open file descriptors into fs
 namespace

On Fri, Aug 07, 2020 at 01:09:30PM +0200, Enrico Weigelt, metux IT consult wrote:
> Hello folks,
> 
> 
> here's the first version of my "srvfs" implementation - a synthentic
> filesystem which allows a process to "publish" an open file descriptor
> into the file system, so other processes can continue from there, with
> whatever state the fd is already in.
> 
> This is a concept from Plan9. The main purpose is allowing applications
> "dialing" some connection, do initial handshakes (eg. authentication)
> and then publish the connection to other applications, that now can now
> make use of the already dialed connection.

Yeah, but...  Linux open() always gets a new struct file instance; how
do you work around that?  Some variant of ->atomic_open() API change?
Details, please.