Re: [PATCH v2 0/3] pidfs: implement file handle support
From: Erin Shepherd
Date: Thu Nov 14 2024 - 07:50:10 EST
On 14/11/2024 08:02, Amir Goldstein wrote:
> On Wed, Nov 13, 2024 at 7:01 PM Erin Shepherd <erin.shepherd@xxxxxx> wrote:
>> Since the introduction of pidfs, we have had 64-bit process identifiers
>> that will not be reused for the entire uptime of the system. This greatly
>> facilitates process tracking in userspace.
>>
>> There are two limitations at present:
>>
>> * These identifiers are currently only exposed to processes on 64-bit
>> systems. On 32-bit systems, inode space is also limited to 32 bits and
>> therefore is subject to the same reuse issues.
>> * There is no way to go from one of these unique identifiers to a pid or
>> pidfd.
>>
>> This patch implements fh_export and fh_to_dentry which enables userspace to
>> convert PIDs to and from PID file handles. A process can convert a pidfd into
>> a file handle using name_to_handle_at, store it (in memory, on disk, or
>> elsewhere) and then convert it back into a pidfd suing open_by_handle_at.
>>
>> To support us going from a file handle to a pidfd, we have to store a pid
>> inside the file handle. To ensure file handles are invariant and can move
>> between pid namespaces, we stash a pid from the initial namespace inside
>> the file handle.
>>
>> (There has been some discussion as to whether or not it is OK to include
>> the PID in the initial pid namespace, but so far there hasn't been any
>> conclusive reason given as to why this would be a bad idea)
> IIUC, this is already exposed as st_ino on a 64bit arch?
> If that is the case, then there is certainly no new info leak in this patch.
pid.ino is exposed, but the init-ns pid isn't exposed anywhere to my knowledge.
>> Signed-off-by: Erin Shepherd <erin.shepherd@xxxxxx>
>> ---
>> Changes in v2:
>> - Permit filesystems to opt out of CAP_DAC_READ_SEARCH
>> - Inline find_pid_ns/get_pid logic; remove unnecessary put_pid
>> - Squash fh_export & fh_to_dentry into one commit
> Not sure why you did that.
> It was pretty nice as separate commits if you ask me. Whatever.
I can revert that if you prefer. I squashed them because there was some churn
when adding the init-ns-pid necessary to restore them, but I am happy to do
things in two steps.
Do you prefer having the final handle format in the first step, or letting it
evolve into final form over the series?