On Wed, May 8, 2024 at 12:32 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Tue, May 07, 2024 at 01:38:42PM -0700, Andy Lutomirski wrote: > > On Tue, May 7, 2024 at 12:42 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > > > > With my kernel hat on, maybe I agree. But with my *user* hat on, I > > > > think I pretty strongly disagree. Look, idmapis lousy for > > > > unprivileged use: > > > > > > > > $ install -m 0700 -d test_directory > > > > $ echo 'hi there' >test_directory/file > > > > $ podman run -it --rm > > > > --mount=type=bind,src=test_directory,dst=/tmp,idmap [debian-slim] > > > > > > $ podman run -it --rm --mount=type=bind,src=test_directory,dst=/tmp,idmap [debian-slim] > > > > > > as an unprivileged user doesn't use idmapped mounts at all. So I'm not > > > sure what this is showing. I suppose you're talking about idmaps in > > > general. > > > > Meh, fair enough. But I don't think this would have worked any better > > with privilege. > > > > Can idmaps be programmed by an otherwise unprivileged owner of a > > userns and a mountns inside? > > Yes, but only for userns mountable filesystems that support idmapped > mounts. IOW, you need privilege over the superblock and the idmapping > you're trying to use. Hmm. Is there a good reason to require privilege over the superblock? Obviously creating an idmap that allows one to impersonate someone else seems like a problem, but if an unprivileged task already "owns" (see below) a UID or GID, then effectively delegating that UID or GID is would need caution but is not fundamentally terrible. So, if I'm 1000:1000, then creating an idmap that makes some other task (that isn't 1000:1000) get to act as 1000:1000 doesn't grant new powers. But maybe something even more general could be done (although I'm not sure this is worthwhile): if I own a userns and that userns has an outside UID 1001 mapped (via newuidmap, for example), then perhaps letting me configure an idmap that grants UID 1001 seems not especially dangerous. But maybe that particular job should also be delegated to newuidmap. Out of an abundance of caution, maybe this whole thing should be opt-in. For example, there could be a new CAP_DELEGATE that allows delegation of one's own uid and gid. The idea is that it should be safe to grant regular users CAP_DELEGATE as an ambient capability. --Andy
