Re: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> 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

> # cat /tmp/file
> hi there
> <-- Hey, look, this kind of works!
> # setpriv --reuid=1 ls /tmp
> ls: cannot open directory '/tmp': Permission denied
> <-- Gee, thanks, Linux!
> Obviously this is a made up example.  But it's quite analogous to a
> real example.  Suppose I want to make a directory that will contain
> some MySQL data.  I don't want to share this directory with anyone
> else, so I set its mode to 0700.  Then I want to fire up an
> unprivileged MySQL container, so I build or download it, and then I
> run it and bind my directory to /var/lib/mysql and I run it.  I don't
> need to think about UIDs or anything because it's 2024 and containers
> just work.  Okay, I need to setenforce 0 because I'm on Fedora and
> SELinux makes absolutely no sense in a container world, but I can live
> with that.
> Except that it doesn't work!  Because unless I want to manually futz
> with the idmaps to get mysql to have access to the directory inside
> the container, only *root* gets to get in.  But I bet that even
> futzing with the idmap doesn't work, because software like mysql often
> expects that root *and* a user can access data.  And some software
> even does privilege separation and uses more than one UID.

If the directory is 700 and it's owned by say root:root on the host and
you want to share that with arbitrary container users then this isn't
something you can do today (ignoring group permissions and ACLs for the
sake of your argument) even on the host so that's not a limitation of
userns or idmapped mounts. That means many to one mappings of uids/gids.

> So I want a way to give *an entire container* access to a directory.
> Classic UNIX DAC is just *wrong* for this use case.  Maybe idmaps
> could learn a way to squash multiple ids down to one.  Or maybe

Many idmappings to one is in principle possible and I've noted that idea
down as a possible extension at quite a while (2 years?) ago.

> I haven't looked at the idmap implementation nearly enough to have any
> opinion as to whether squashing UID is practical or whether there's

It's doable. The interesting bit to me was that if we want to allow
writes we'd need a way to determine what the uid/gid would be to write
down. Imho, that's not super difficult to solve though. The most obvious
one is that userspace can just determine it when creating the idmapped

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux