From: Lennart Poettering <[email protected]> Date: Tue, 08 Sep 2026 08:37:45 -0500 > On Mo, 07.09.26 16:54, Skye Soss ([email protected]) wrote: > > > From: Lennart Poettering <[email protected]> > > Date: Mon, 07 Sep 2026 11:50:47 -0500 > > > Huh, what's the usecase for this? why would you want to combine that? > > > i don't get it? > > > > > > I'd normally expect people to either use subuids and the stuff that > > > comes with it, or uses nsresoured stuff, but i fail to see why you'd > > > want both for the same container? > > > > This isn't for containers, but instead for programs like Disk Usage > > Analyzer or trash-utils that work on > > arbitrary files owned by users. A user should be able to create a user > > namespace where they have access > > to all of "their own" files for management, organization, searching, > > indexing, etc. > > Uh, that's not really how nsresourced is designed.
I'm not referring to the transient uid aspect, just the foreign uid aspect. > But why do you have to have > access to *all* of them from the *same* process at the *same* process? > I'd always expect you fork off workers that join the processes > individually, operate on one of them each, and exit when done? This would require rewrites of core command line programs for managing files like `rm`, `du`, `find`, etc. I don't think rewriting every one of those tools is the correct path forward, as opposed to a single `podman unshare`-style script that drops you into a namespace where you have read access to every file you own. The other use-case is for running `du` without needing to modify file permissions. The command `unshare --map-root-user --map-subids du -hs ~/somedir` used to let users reliably calculate the disk usage of a directory a user had previously created. Now that foreign ids can be mapped *independently*, this is no longer possible in general (consider creating a 777 directory with one method, then later modifying it to 700). Allowing foreign ids to be mapped with shadow-utils closes this gap. Skye
