[SOLVED] Trying to get more info about the uid gid mapping

V

vacar84

Member
Feb 23, 2021
18
1
8
40
Hello all

I've been searching throughout the forum for few days and found several threads related to this topic but each of them was missing some small piece of information which could lead me to the resolution of my issue.

Briefly this is my current configuration: ProxMox virtual server with an usb hub where I installed 5 hard drives. All of them have been mounted to the host via fstab using their respective uuids. This is working ok so far. I'm now in the need of creating a mount point in one container (unprivileged) and I get the write permission issue as expected.
Now, looking at the options I have I'd like to do what it's written here but I'm stuck at the point where I have to enter the right uid and gid. Wtihin the host I have only the root user and the same goes within the container, so I'd simply be able to use the root user in the container and write to the mount point using that.

Should it be something like this?

Code: 
# Add to /etc/pve/lxc/<container_id>.conf:
lxc.idmap: u 0 100000 0
lxc.idmap: g 0 100000 0
lxc.idmap: u 0 0 1
lxc.idmap: g 0 0 1
lxc.idmap: u 1 100109 65427
lxc.idmap: g 1 100115 65421


# Add to /etc/subuid:
root:0:1

# Add to /etc/subgid:
root:0:1
 
If you follow the example as is, it should work. Just note that following the steps, you must also change the owner of the mountpoint on the host with chown -R 1005:1005 /mnt/bindpoint/shared.

vacar84 said:
Wtihin the host I have only the root user and the same goes within the container
Click to expand...
This isn't a problem. All your doing is mapping a uid within the container to one on the host, so the choice of uid is somewhat arbitrary.

Depending on your use case, you could also just make the shared directory world read/writable, by running chown 777 /mnt/bindpoint/shared from the host
 
Last edited:
  • Like
Reactions: vacar84
vacar84 said:
Should it be something like this?

Code: 
# Add to /etc/pve/lxc/<container_id>.conf:
lxc.idmap: u 0 100000 0
lxc.idmap: g 0 100000 0
lxc.idmap: u 0 0 1
lxc.idmap: g 0 0 1
lxc.idmap: u 1 100109 65427
lxc.idmap: g 1 100115 65421


# Add to /etc/subuid:
root:0:1

# Add to /etc/subgid:
root:0:1
Click to expand...
I think that should be more like:
lxc.idmap: u 0 0 1
lxc.idmap: g 0 0 1
lxc.idmap: u 1 100001 65565
lxc.idmap: g 1 100001 65565

And from the point of security you might want not to use root for everything. Would be better if you run your services with a unprivileged user.
 
  • Like
Reactions: vacar84
Thank you all for the replies!

Yes I wanted to change the user I run my services with. So I want to do that, let's assume I'll use a user called "download" on a container where I run debian with a torrent client installed, such a user exists in the CT with uid, I don't know, 105. Does it mean I have to create the same user within the host and then map it or I can just map all CT users to the root user on the host on all CTs? This is the part where I get lost...

sorry for the dumb questions.. :(
 
vacar84 said:
Thank you all for the replies!

Yes I wanted to change the user I run my services with. So I want to do that, let's assume I'll use a user called "download" on a container where I run debian with a torrent client installed, such a user exists in the CT with uid, I don't know, 105. Does it mean I have to create the same user within the host and then map it or I can just map all CT users to the root user on the host on all CTs? This is the part where I get lost...

sorry for the dumb questions.. :(
Click to expand...
If you map something to root on the host it's again bad for security, because that unprivileged LXC user then got root access on the host. So best thing is to map a unprivileged user inside the LXC to a unprivileged user on the host.
You don't need to create a "download" user with UID 105 on the host. If you don't create it the folder will still be owned by UID 105 even if there is no such user defined. But it would be way easier to manage stuff if you also create that user on the host.

And by the way, LXCs aren't good for privacy. I would use VMs for that. They are way better isolated and you got more options to setup your network (additional virtual NIC for VPN and so on).
 
Last edited:
  • Like
Reactions: dylanw
Ok starting to get it a little bit better now. If I understood correctly the way it works, I could just follow this example:

Code: 
# uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), so 0..1004 (ct) → 100000..101004 (host)
lxc.idmap = u 0 100000 1005
lxc.idmap = g 0 100000 1005
# we map 1 uid starting from uid 1005 onto 1005, so 1005 → 1005
lxc.idmap = u 1005 1005 1
lxc.idmap = g 1005 1005 1
# we map the rest of 65535 from 1006 upto 101006, so 1006..65535 → 101006..165535
lxc.idmap = u 1006 101006 64530
lxc.idmap = g 1006 101006 64530

Just need to create the user with uid 105 (If I want to follow the example) within the container and apply the mapping to the CT config and that's it, is that correct ?
 
So I tried it. It worked just fine.

There's just one weird thing. I had to re-create the container from scratch, therefore I lost the config file with all the mapping. So I now have only this setting in my /etc/subgid and /etc/subuid files:
Code: 
root:100000:65536
root:107:1

However, when I try now to write a file in the shared directory, it works anyway and doesn't return the permission issue anymore. Is it supposed to work this way? Or most likely I really didn't get the way it works ?
 
Do you happen to have the permissions on the shared folder set to world writable (check the access field of stat /mnt/bindpoint/shared)?
 
In theory, without the remapping step, you shouldn't be allowed to write to the directory from the container, because you'd be writing as a totally different user.
Perhaps when you reconfigured it, you accidentally made it a privileged container? This would mean that container uid 0 is mapped to host uid 0, i.e., you are operating with host root privileges, so have permission on the directory (not a recommended approach) [1].

All /ect/subuid specifies is a range of uids that a user (in the below case, root) can use [2]:
Code: 
root:100000:65536
root:107:1

The lxc mapping in the container config then specifies uids/gids in the container and the uids/gids which they are mapped to on the host (see section "UID Mappings" of [3]). So in the example container configuration, you're basically saying map host uids 100000-101004 to CT uids 0-1004, then map host uid 1005 to CT uid 1005, finally map host uids 101006-165535 to CT uid 1006-65535. As a result, 1005 relates to the same user on host and CT, while the rest are mapped to random unprivileged users on the host.

[1] https://linuxcontainers.org/lxc/security/
[2] https://man7.org/linux/man-pages/man5/subuid.5.html
[3] https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html
 
  • Like
Reactions: Dunuin
dylanw said:
In theory, without the remapping step, you shouldn't be allowed to write to the directory from the container, because you'd be writing as a totally different user.
Perhaps when you reconfigured it, you accidentally made it a privileged container? This would mean that container uid 0 is mapped to host uid 0, i.e., you are operating with host root privileges, so have permission on the directory (not a recommended approach) [1].

All /ect/subuid specifies is a range of uids that a user (in the below case, root) can use [2]:
Code: 
root:100000:65536
root:107:1

The lxc mapping in the container config then specifies uids/gids in the container and the uids/gids which they are mapped to on the host (see section "UID Mappings" of [3]). So in the example container configuration, you're basically saying map host uids 100000-101004 to CT uids 0-1004, then map host uid 1005 to CT uid 1005, finally map host uids 101006-165535 to CT uid 1006-65535. As a result, 1005 relates to the same user on host and CT, while the rest are mapped to random unprivileged users on the host.

[1] https://linuxcontainers.org/lxc/security/
[2] https://man7.org/linux/man-pages/man5/subuid.5.html
[3] https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html
Click to expand...
Thanks a lot for the detailed explanation! I'm now starting to understand it a little bit better :)
To your assumption, the CT doesn't look to be privileged:
1614340642792.png

This is a screenshot from that container shell where you can see I can touch the shared folder:

1614340711491.png

and this is how the mountpoint was created:
1614340746537.png

and this is all I have in the CT config file on the host:
1614340933536.png

Do you see anything wrong?
 
All the configuration looks fine to me. Could you also check the permissions on the two sub directories "DIR05" and "DownloadFolder"?
 
Ah yes, that's the reason. If you do chmod -R 755 /root/mount_point/DIR05, you shouldn't be able to write the directories from the container anymore. And following the id mapping steps should then enable you to write again :)
 
dylanw said:
Ah yes, that's the reason. If you do chmod -R 755 /root/mount_point/DIR05, you shouldn't be able to write the directories from the container anymore. And following the id mapping steps should then enable you to write again :)
Click to expand...
Got it. It actually makes sense.. Thank you!
 
No problem! Let me know if you have any more trouble with it. If not, would you kindly mark the thread as solved so others can find it easier? I think we've built up quite a good reference guide here ;)
 
Sure! Would you mind if before marking it as solved I try to do all the above steps? You know, I'd like to avoid to open another thread in case of further issue, since I'm not sure I can edit it once it's marked as solved..
 
You can mark it as solved by yourself. Use the "Edit Thread" button at the top right of the thread and change it from "no prefix" to "solved".
That won't close it. Acutally I have never seen a closed thread in this forum.
 
  • Like
Reactions: dylanw and vacar84
You must log in or register to reply here.
Top Bottom