Skip to content

Conversation

@DaanDeMeyer
Copy link
Member

No description provided.

Copy link
Member

@behrmann behrmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Starting at line 644 is the section of finished items, so it needs to move above that line.

Comment on lines +1022 to +1024
### A way to iterate process file descriptors without /proc

[x] A way to iterate process file descriptors without needing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### A way to iterate process file descriptors without /proc
[x] A way to iterate process file descriptors without needing
### A way to iterate over process file descriptors without /proc
A way to iterate over process file descriptors without needing

@dvdhrm
Copy link
Member

dvdhrm commented Nov 27, 2025

Wouldn't it be much nicer if we could call fsmount(fsopen("procfs")) and then use the temporary mount via *at() syscalls?

This is already possible by calling fork()+CLONE_NEWUSER+CLONE_NEWMOUNT and then calling fsmount(fsopen("procfs")). But the requirement for this fork is annoying, and the kernel currently magically hides procfs if not already visible via other means.

So, maybe instead of providing duplicate APIs that /proc already has, we can instead ensure that access to at least /proc/self/ is readily available?

(I am no huge fan of file-system based APIs like /proc, but I mean... it is there... we have it, so we can just make use of it)

@DaanDeMeyer
Copy link
Member Author

That would indeed do the trick, and in my case I already have a user and mountns, so let me close this.

@dvdhrm
Copy link
Member

dvdhrm commented Nov 27, 2025

Nooooo, I need someone to push this forward! :'(

@Werkov
Copy link

Werkov commented Nov 28, 2025

But the requirement for this fork is annoying,

Can't you merely unshare(CLONE_NEWUSER|CLONE_NEWMOUNT) without the fork?

@dvdhrm
Copy link
Member

dvdhrm commented Dec 1, 2025

But the requirement for this fork is annoying,

Can't you merely unshare(CLONE_NEWUSER|CLONE_NEWMOUNT) without the fork?

Yes, I can, but then I cannot switch back to my original user-namespace. Even if I retain a namespace-fd to the original user-ns, a setns(2) call is not allowed, since it always grants full privileges and wouldn't be allowed for an unprivileged caller.

So yes, I can get access to proc by dropping namespaces, but it would lock you out from joining the previous user-namespace. By doing this in a fork, you can pass back the FD but retain your namespaces in the parent process.

@keszybz keszybz reopened this Dec 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants