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

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

Date:   Mon, 10 Aug 2020 13:27:18 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Al Viro <viro@...iv.linux.org.uk>,
        "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 07.08.20 18:23, Al Viro wrote:

Hi,

>> 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; 

I know :(

> how
> do you work around that?  Some variant of ->atomic_open() API change?
> Details, please.

Proxy struct file. Yes, this adds lots of bloat :(

https://github.com/metux/linux-srvfs-oot/blob/master/kernel/proxy.c

I thought about some possible ugly tricks of copying over one into
another, but that could easily end up in a desaster.

Another idea would be adding a new fs-op that returns it's own struct
file - basically kinda per-fs open() syscall - which is called instead
of .open, if defined.

But for now, I tried to implement it as oot-module (and submit for
mainline later), so it could also be used on existing distro kernels.

Maybe that's not the best idea at all :o

What'd be your suggestion ?



--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287