[lxc-users] Unprivileged containers and Linux Capabilities

[Michele Giacomoli]

Thank you,
So, as result, there is no way to keep capabilities for unprivileged 
containers, and lxc.cap.drop/keep in this case are pretty useless. Am I 
right?

Best Regards
Michele

Il 18/05/2016 16:49, Serge E. Hallyn ha scritto:
> No.  You cannot give a non-initial user ns capabilities against
> the initial user ns.  Kernel simply doesn't support it.  You could
> leave a channel open for the container to make requests of a daemon
> which runs on the host.  That's how the cgmanager proxy worked,
> talking over a unix socket to the cgmanager on the host.
>
> On Wed, May 18, 2016 at 09:57:11AM +0200, Michele Giacomoli wrote:
>> Thank you Serge
>>
>> Is there a way for managing user namespace capabilities and add
>> needed capabilities to initial user namespace?
>>
>> Best regards
>> Michele
>>
>> Il 17/05/2016 16:43, Serge E. Hallyn ha scritto:
>>> On Tue, May 17, 2016 at 10:32:18AM +0200, Michele Giacomoli wrote:
>>>> HI all,
>>>>
>>>> I have an Ubuntu 14.04 host with lxc 1.0.3-0ubuntu3. I created an
>>>> unprivileged container with the following capabilities dropped from
>>>> /usr/share/lxc/config/ubuntu.common.conf template:
>>>> lxc.cap.drop = sys_module mac_admin mac_override sys_time
>>>> This is the configuration for the container:
>>>>
>>>> lxc.include = /usr/share/lxc/config/ubuntu.common.conf
>>>> lxc.include = /usr/share/lxc/config/ubuntu.userns.conf
>>>> lxc.arch = x86_64
>>>>
>>>> lxc.id_map = u 0 123456 65536
>>>> lxc.id_map = g 0 123456 65536
>>>> lxc.rootfs = /mypath/
>>>> lxc.utsname = mycontainer
>>>>
>>>> # Network configuration
>>>> lxc.network.type = veth
>>>> lxc.network.flags = up
>>>> lxc.network.link = mylink
>>>> lxc.network.name = eth0
>>>> lxc.network.hwaddr = my:ma:ca:dd:re:ss
>>>>
>>>> A really basic config file
>>>>
>>>> I installed a program inside this container which claims it fails
>>>> when calling function pthread_setschedparam. This function should be
>>>> permitted when CAP_SYS_NICE capability is not dropped (and this
>>>> seems to be the case). I also had same problem in the past when
>>>> trying to let a guest change system clock (that time I removed
>>>> sys_time from dropped capabilities).
>>>> My questions are: are capabilities taken in consideration when
>>>> dealing with unprivileged containers? Do I have something more to do
>>>> so that I can use this functions inside an unprivileged container?
>>>>
>>>> Best Regards
>>>> Michele
>>> Capabilities are targeted to a user namespace.  If a modifying a
>>> resource can adversely affect the host, then you'll need the
>>> related capability targeted at the initial user namespace, rather
>>> than your own.  (In the kernel source this is the difference between
>>> capable(CAP_SYS_NICE) and ns_capable(ns, CAP_SYS_NICE), where
>>> capable(x) expands to ns_capable(&init_user_ns, x).
>>>
>>> So the feature you're trying to set in the container likely requires
>>> the capaability against the initial user ns.  Your container cannot
>>> have that.
>>>
>>> -serge
>>> _______________________________________________
>>> lxc-users mailing list
>>> lxc-users at lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>> _______________________________________________
>> lxc-users mailing list
>> lxc-users at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users