Let’s say I have user alice@host (1000) user bob@c1 (1000) inside container c1.
I configure c1 as follows:
config:
raw.idmap both 1000 1000
Files owned by alice on the host now appear as owned by bob from within c1. What does this mean in terms of actual privileges? Is bob is still e.g. uid 1001000 from the host’s point of view? If so, is there some special back-and-fourth uid/suid translation of file ownership at work here?
By observing process ids, I have come to the conclusion that raw.idmap does in fact create a 1:1 mapping that discards the uid/suid distinction. bob@c1 runs as alice@host (1000) on the host, not as 1001000.
This removes the need for any transparent ownership translation I had dreamed up to make sense of this.
Please confirm/deny my conclusion so I can progress and (if correct) mark my own reply as a solution. Thanks!
I will move on to trying shiftfs, which seems to offer an elegant solution to the problem of sharing directories.
that’s correct, raw.idmap as showed above will make it so that anything that’s got to do with uid/gid 1000 in the container will happen as the real uid/gid 1000 outside the container.
This is convenient for file sharing but does come with the downside that you can mess with other user-owned resources limit user limits, potentially affecting processes outside of the container.
Not using raw.idmap but instead using a disk device with the shift property enabled (using shiftfs) should achieve the same without the need for the shared uid/gid.
Note that we still don’t turn shiftfs on by default as we’re waiting for a few last kernel fixes to land (caching issues and support for stacking overlayfs on top of shiftfs mostly).
