Allow per-disk ID map

[intelfx]

Is there an existing issue for this?

• There is no existing issue for this feature

What are you currently unable to do

I would like to mount host paths into Incus-launched containers while being able to control the UID:GID these paths appear as within the container.

For instance, I might want to mount a configuration file owned by the current user, but in such a way that the container would think it is owned by root (or a pre-determined daemon user).

Currently, it is only possible to make the path appear either under the same UID:GID values as on the host (shift=true) or under the nobody user (shift=false).

What do you think would need to be added

It would be nice to have a more fine-grained way to control idmapping of host mounts (what is currently achieved via the shift=<bool> disk device option).

In the simplest case, I propose a shift-to=<UID>[:<GID>] option that would translate the IDs in such a way that the mounted entry appears as owned by : inside the container.

Current behavior

$ stat /path/to/file
  File: /path/to/file
<...>
Access: (0644/-rw-r--r--)  Uid: ( 1000/ intelfx)   Gid: ( 1000/ intelfx)
<...>

$ incus config device add MYCONTAINER MYFILE disk source=/path/to/file path=/file shift=true
Device MYFILE added to MYCONTAINER

$ incus exec arch -- stat /file
  File: /file
<...>
Access: (0644/-rw-r--r--)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1000/ UNKNOWN)
<...>

Suggested behavior

$ stat /path/to/file
  File: /path/to/file
<...>
Access: (0644/-rw-r--r--)  Uid: ( 1000/ intelfx)   Gid: ( 1000/ intelfx)
<...>

$ incus config device add MYCONTAINER MYFILE disk source=/path/to/file path=/file shift-to=0
Device MYFILE added to MYCONTAINER

$ incus exec arch -- stat /file
  File: /file
<...>
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
<...>

[stgraber]

I think the way we'd try to do something like this is by having a per-disk raw.idmap using the same syntax as for the instance, configuring the relevant VFS idmap config accordingly.

This isn't exactly trivial to implement as today we can just clone the idmap from the container whereas for this, we'd need to build another map just for the mount and then pass that to the kernel.

[intelfx]

@stgraber Is there any chance that a friendlier UI for this than a raw.idmap equivalent (which is not even fully documented in the reference) can be in scope for the project?

I'd say the task of "make path X to appear like UID Y" is likely more common than the detailed knowledge of VFS ABI internals.

[stgraber]

Our raw.idmap syntax is already doing what you're describing.
It's basically uid <host> <guest>, gid <host> <guest> or both <host> <guest>.

So make /home/user/foo owner by 1000:1000 show up as /mnt/foo owner by 0:0 would look like:

incus config device add INSTANCE DEVICE disk source=/home/user/foo path=/mnt/foo shift=true raw.idmap="both 1000 1000"

[TCB13]

Our raw.idmap syntax is already doing what you're describing. It's basically uid <host> <guest>, gid <host> <guest> or both <host> <guest>.

So make /home/user/foo owner by 1000:1000 show up as /mnt/foo owner by 0:0 would look like:

incus config device add INSTANCE DEVICE disk source=/home/user/foo path=/mnt/foo shift=true raw.idmap="both 1000 1000"

Yes it does, however it wont allow different peer mount ID maps.

Consider this use case for a safer shared-hosting cpanel-like setup:

• Each website get's a directory on the host: /vhosts/siteA.

• Each vhost files on the host should be owned as a isolated user i.e. siteA => 50001

• One Apache container e.g. shared-apache

• One php-fpm container per website, e.g. php-siteA

• All containers running with security.idmap.isolated=true and all mount as shift=false

• Mount /vhosts/siteA.com to container php-siteA under /mnt/weboot

• Mount /vhosts/siteA.com to container shared-apache under /mnt/vhosts/siteA
  (do the same for siteB, siteC etc.)

Now, assuming:

• www-data inside shared-apache -> 1000997 on the host
• www-data inside php-siteA -> 1100997 on the host
• My objective is to make sure both php, apache all have read/write access to each other files - because Apache may need to write uploads, logs and others and have those files picked / edited by php.

I can set this on the containers:

• shared-apache -> raw.idmap: both 50001 33
• php-siteA -> raw.idmap: both 50001 33

This works fine for a single vhost, because when apache writes from www-data inside its container the files will be actually 50001 in the host and that's going to be then mapped to the php's container www-data user.

Problem is, when we've more vhosts doing something like:

raw.idmap: 
  both 50001 33      -> for /mnt/vhosts/siteA
  both 50002 33      -> for /mnt/vhosts/siteB

It will not work properly when Apache writes a log into /mnt/vhosts/siteB/logs/error.log. The resulting file will be owned by 50001 at the host level instead of 50002. And of course the php-siteB won't be able to read/write to that file.

I don't see a way of working around this while keeping the isolation. I could map every php container www-data user into the same host uid e.g. 5000 but that would mean all the vhost files would be owned by the same user... same goes for all the php processes running inside the containers.

The ideal scenario would be to have per-mount ID maps like this:

• shared-apache's mount /mnt/vhosts/siteA -> raw.idmap: both 50001 33
• shared-apache's mount /mnt/vhosts/siteB -> raw.idmap: both 50002 33

So that when apache wrote as www-data inside /mnt/vhosts/siteA it would appear on the host as 50001, while writes as www-data inside /mnt/vhosts/siteB would appear as 50002.

Much appreciated.

[stgraber]

Yes, that's what I'm saying, we'd add a raw.idmap at the disk level with the same syntax as the raw.idmap at the instance level.

[TCB13]

Yes, that's what I'm saying, we'd add a raw.idmap at the disk level with the same syntax as the raw.idmap at the instance level.

Thanks for the confirmation. This feature will be very helpful for situations like the one I described.