Allow ID maps per instance

Problem/Justification
Ability to map a user in the container to a user in truenas for permissiong disks. Today the idmap user is common across all instances.

For example mapping root in a container to user 3001 in truenas. Having that user be a named user/group on dataset permissions.

This would increase visibility of which container has access to what filesystem resources.

This would reduce the chance of cross-instance ‘confusion’ where the user in one instance gets access to the file system of another instance stored in a dataset or path used by both instances.

It would also allow differention of users for both assigning permissions and logging - for example root in a file downloader instance could have r/w permissions while the same user in the serving instance (say root in both cases) would have only r to the same data set. It would be in logs which container performed what action. Today any logs would just show ‘apps’ did it.

Impact
By default there should be no impact, the default behaviour we have today in fangtooh can be maintained. This would optionall allow users to give each instance its own idmap and avoid the current generic user that is applied.

In terms of development impact this leverages pre-exisiting idmap features of incus. These features cannot be used today because if idmaps are configured at the command line the custom ix-systems incus orchestrator overwrites them. This could be rolled out by first just changing that behaviour in phase 1 with an ‘allow custom id maps’ option that would allow it to be set by CLI and not over written. Later phases could add UI. Later still would be better workflow to create the users to do this in the truenas UI.

User Story
Create one instance where root (user 0) in container A is mapped to user 3001
Create second instance where root (user 0) in container B is mapped to user 3002
These users would have no login permissions and no truenas user permissions.

on a dataset to be mounted in both containers allow the dataset to be owned by user 3001 who has rwx rights. Add user 3002 to same dataset permissions as rw.

4 Likes

I would like to be able to map apps(568/host) to first user(1000/instance).

I believe there’s already a user mapping for 1000 host to 1000 intance, and i don’t believe that can be changed

The first local user id created by truenas is 3000, so it is unlikely that there is a user with id 1000 in host.

BTW: 568/host => 1000/instance This should be a user-definable setting.

According to the docs, the uid mapping for incus vms/instances start with a local user at 2147000001 which maps to root in the vm/instance. And according to the docs it can be changed.

Edit:

And on my instance tab i can create new user mappings and map e.g. 568 to any user inside the instance

I tried to remove the default mapping (568=>568) in the web ui, and the system says:

Validation Error
[EINVAL] user_update.userns_idmap: This attribute cannot be changed.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/ws_handler/rpc.py", line 323, in process_method_call
    result = await method.call(app, params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/method.py", line 40, in call
    result = await self.middleware.call_with_audit(self.name, self.serviceobj, methodobj, params, app)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 906, in call_with_audit
    result = await self._call(method, serviceobj, methodobj, params, app=app,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 715, in _call
    return await methodobj(*prepared_call.args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/service/crud_service.py", line 266, in update
    return await self.middleware._call(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 726, in _call
    return await self.run_in_executor(prepared_call.executor, methodobj, *prepared_call.args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 619, in run_in_executor
    return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/service/crud_service.py", line 294, in nf
    rv = func(*args, **kwargs)
         ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/decorator.py", line 101, in wrapped
    result = func(*args)
             ^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/plugins/account.py", line 859, in do_update
    verrors.check()
  File "/usr/lib/python3/dist-packages/middlewared/service_exception.py", line 72, in check
    raise self
middlewared.service_exception.ValidationErrors: [EINVAL] user_update.userns_idmap: This attribute cannot be changed

It may be possible from the command line, but I’m worried about losing the settings with a system upgrade.

Ok then 568:568 is hardcoded, did not know that.

yes, that’s the reason for the request

having all instances run in the same mapping is not idea for isolating one container from another as they use files on the truenas filesystem…

Registered on the forums to +1 for this feature :slightly_smiling_face:

I’m playing around with containers in 25.04, and with the current global idmap it’s possible to add non-root user in the container that maps to the host user. But it would be nice to have per-container idmap, so container root could map to different host users depending on container.

1 Like