linux-kernel - RFC: allow recording and passing of open file descriptors

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-next>] [day] [month] [year] [list]

Date:   Tue, 29 Jun 2021 16:43:39 +0200
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     linux-kernel@...r.kernel.org
Cc:     viro@...iv.linux.org.uk, info@...ux.net, keescook@...omium.org,
        anton@...msg.org, ccross@...roid.com, tony.luck@...el.com,
        linux-fsdevel@...r.kernel.org
Subject: RFC: allow recording and passing of open file descriptors

Hello folks,

here's an attempt to make it to record open file descriptors (struct file*)
and make them available to other processes via file system. The semantics
are similar to dup() or passing via Unix socket in regard that the 
receiving process will get reference to the same struct file instance into
its fdtable. But the big difference here is we're doing it directly via
file system (ie. retrieving is done by a simple open()). It works pretty
much like like Plan9's /srv file system:

    http://man.cat-v.org/plan_9/3/srv

To archive that, the first patch introduces the concept of "file boxing",
which means an open file operation can put a reference to another file
into the struct file, which will then be returned to the caller, instead
of the newly created one. The reason for doing it this strange way is that
the new struct file instance is allocated and prepared very early, before
we're calling into the actual file operation - refactoring this so that
the open() file op directly returns a struct file* pointer would be a
massively intrusive change, that I just don't dare to do here.

The second patch introduces a new file system "srvfs" that works like
Plan9's /srv file systems.

Another use case for the first patch could be direct fd passing in FUSE,
like Peng Tao and Alessio Balsini are currently working on, via other means.

    https://www.spinics.net/lists/linux-fsdevel/msg196163.html

I believe the patch 1 should be pretty straightforward and not doing any harm.
(it's not even compiled in unless explicitly enabled by something else)

have run,

--mtx

---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287