Skip to main content

Proxmox: Unprivileged LXC Workaround

Unprivileged LXC Workaround

Overview of the Problem

  • Join Linux Container to the Active Directory domain
  • Cannot SSH into the Linux Container with domain account
  • This is due to domain account's UID and GID assigned by sssd
    • High UID and GID does not fall within valid range set by PVE
    • Reference the Proxmox VE documentation and note the following
      • uid: 0 and gid: 0 -- root user -- inside the LXC
      • Maps to a high UID and GID in PVE
      • Prevents root access in the event of container escape
root:100000:65536

/etc/subuid and /etc/subgid on the PVE host

Referencing man subuid, you'll note that this indicates that starting from UID / GID 100000, there can be 65,536 mappings for the root user; effectively 100000 -- 165535. This is defined for root, as this is the default user when a new Linux Container is created.

Demonstrating the Problem

image.png
uid and gid mapping for domain.admin@ad.lab

The problem here is that the uid and gid mappings used by sssd when syncing domain users and groups are higher than the 1000000 id in the original config.

The Solution

Some Key Points
  • We should allow a higher subordinate user and group ID mapping
  • That way the higher UID and GID mappings used by sssd will fall within a valid range and accepted by PVE

id domain.admin@ad.lab indicates the uid of 519801105 and the gid of 519800513, 519800512, 519800572 in the example above.

There's nothing wrong with using a higher value as shown in the Reddid thread linked above. I simply didn't need it, because the range I chose is sufficiently large enough to cover the uid and gid output as shown in the id domain.admin@ad.lab command.  

  • The uid and gid ranges are going to vary between Active Directory environments
  • Before you apply the solution, understand the necessary range as required by your environment
  • Inspect users and groups using the id command on your Linux

 

Apply the Solution

Run these commands on the PVE node. The syntax 50000000:9999999 indicates that we'll have a range of available for user and group IDs spanning 50000000 -- 59999998.

cp /etc/subuid /tmp/subuid.bak
cp /etc/subgid /tmp/subgid.bak
echo 'root:500000000:99999999' >> /etc/subuid
echo 'root:500000000:99999999' >> /etc/subgid

One more piece to the puzzle yet... We need to tell the Linux Container that it should use this mapping, while still continuing to use its original mappings for the root user. 

container_id=184
cp "/etc/pve/lxc/$container_id.conf" "/tmp/$container_id.conf.bak"
echo 'lxc.idmap = u 0 100000 65536' >> "/etc/pve/lxc/$container_id.conf"
echo 'lxc.idmap = g 0 100000 65536' >> "/etc/pve/lxc/$container_id.conf"
echo 'lxc.idmap = u 500000000 500000000 99999999' >> "/etc/pve/lxc/$container_id.conf"
echo 'lxc.idmap = g 500000000 500000000 99999999' >> "/etc/pve/lxc/$container_id.conf"
pct reboot $container_id

The u 500000000 500000000 99999999 and g 500000000 500000000 99999999 syntax indicates that any user or group starting with the ID of 500000000 should begin using the mappings. If everything is working, clean up your backed up files:

rm /tmp/subuid.bak
rm /tmp/subgid.bak
rm "/tmp/$container_id.conf.bak"
Back to top