lxc copy between hosts preserves original uid/gid

Bug #1699919 reported by PshemK
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lxc (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I tried to copy an lxc container between two hosts. All worked as expected, but when I looked at the underlying filesystem I realised that the container that has been copied onto the new machine retained its original uid/gid (running unprivileged):

root@ii:/var/lib/lxd/containers# ls -al
total 24
drwx--x--x 1 root root 58 Jun 23 12:01 .
drwxr-xr-x 1 root root 182 Jun 23 12:04 ..
drwxr-xr-x+ 1 100000 100000 56 Jun 23 10:38 backend
-rw-r--r-- 1 root root 4446 Jun 23 12:04 lxc-monitord.log
drwxr-xr-x+ 1 100000 100000 56 Jun 23 12:01 putils

(putils has been copied from a different host).

I'd expect a new uid/gid to be allocated for the copied host.

Revision history for this message
Christian Brauner (cbrauner) wrote :

Hi, I'm not sure what the problem here is. LXD will copy the filesystem mapped and will remap on demand if there's another sub{g,u}id range allocated for LXD on the new host.

Revision history for this message
PshemK (pshem-k) wrote :

The thing is - it didn't get remapped. Now I have two containers mapping to the same range, both live:

pshemk@ii:~$ lxc list
+---------+---------+---------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+---------+---------+---------------------+------+------------+-----------+
| backend | RUNNING | 10.221.22.92 (eth0) | | PERSISTENT | 0 |
+---------+---------+---------------------+------+------------+-----------+
| putils | RUNNING | 10.221.22.91 (eth0) | | PERSISTENT | 1 |
+---------+---------+---------------------+------+------------+-----------+

pshemk@ii:~$ lxc config show putils
architecture: x86_64
config:
  volatile.base_image: 8fa08537ae51c880966626561987153e72d073cbe19dfe5abc062713d929254d
  volatile.eth0.hwaddr: 00:16:3e:e3:20:21
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  root:
    path: /
    type: disk
ephemeral: false
profiles:
- default
stateful: false
pshemk@ii:~$ lxc config show backend
architecture: x86_64
config:
  volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
  volatile.eth0.hwaddr: 00:16:3e:ec:03:84
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  root:
    path: /
    type: disk
ephemeral: false
profiles:
- default
stateful: false

both have the same hostid, and get mapped to the same range.

Should the files on the file system belong to the same uid:gid for 2 different containers?

Revision history for this message
Christian Brauner (cbrauner) wrote : Re: [Bug 1699919] Re: lxc copy between hosts preserves original uid/gid
Download full text (4.2 KiB)

On Fri, Jun 23, 2017 at 10:19:46AM -0000, PshemK wrote:
> The thing is - it didn't get remapped. Now I have two containers mapping
> to the same range, both live:
>
> pshemk@ii:~$ lxc list
> +---------+---------+---------------------+------+------------+-----------+
> | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
> +---------+---------+---------------------+------+------------+-----------+
> | backend | RUNNING | 10.221.22.92 (eth0) | | PERSISTENT | 0 |
> +---------+---------+---------------------+------+------------+-----------+
> | putils | RUNNING | 10.221.22.91 (eth0) | | PERSISTENT | 1 |
> +---------+---------+---------------------+------+------------+-----------+
>
> pshemk@ii:~$ lxc config show putils
> architecture: x86_64
> config:
> volatile.base_image: 8fa08537ae51c880966626561987153e72d073cbe19dfe5abc062713d929254d
> volatile.eth0.hwaddr: 00:16:3e:e3:20:21
> volatile.idmap.base: "0"
> volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.power: RUNNING
> devices:
> root:
> path: /
> type: disk
> ephemeral: false
> profiles:
> - default
> stateful: false
> pshemk@ii:~$ lxc config show backend
> architecture: x86_64
> config:
> volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
> volatile.eth0.hwaddr: 00:16:3e:ec:03:84
> volatile.idmap.base: "0"
> volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
> volatile.last_state.power: RUNNING
> devices:
> root:
> path: /
> type: disk
> ephemeral: false
> profiles:
> - default
> stateful: false
>
> both have the same hostid, and get mapped to the same range.
>
> Should the files on the file system belong to the same uid:gid for 2
> different containers?

Yes, that is expected and is the default behavior.
What you want is to set

 security.idmap.isolated

for the container. For example,

 lxc config set putils security.idmap.isolated true

this will kick-off an algorithm that will try to find an isolated idmapping for
the container with that property. If you wanted to isolate each container then
you could set

 security.idmap.isolated

to true in an appropriate profile (e.g. the default profile). Note however, that
the number of container with isolated idmaps is restriced by the available
range.
In general, isolating container idmappings makes a lot of sense for security
critical containers. It likely doesn't need to be the default for most of your
workload.

>
> --
> You received this bug notification because you are a member of Ubuntu
> containers team, which is ...

Read more...

Revision history for this message
Stéphane Graber (stgraber) wrote :
Changed in lxc (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.