Re: lxc-start: Invalid argument - failed to remove CAP_SYS_BOOT capability

[Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>]

Michael Tokarev wrote:
> The message in $subj is displayed (and the utility fails) when
> trying to start a container on any of my systems.  I traced it
> to failing prctl(PR_CAPBSET_DROP, CAP_SYS_BOOT).  According to
> the manpage:
>
>    The call fails with the error: EPERM if the calling thread does
>    not have the CAP_SETPCAP; EINVAL if arg2 does not represent a
>    valid capability; or EINVAL if file capabilities are not
>    enabled in the kernel, in which case bounding sets are not sup‐
>    ported.
>
> and the corresponding kernel config is SECURITY_FILE_CAPABILITIES,
> which is in "Security options" menu named "File POSIX Capabilities".
>
> This is a config option that's not checked by lxc-checkconfig, but
> since not setting it entirely prevents lxc from working, I think it
> should be checked too.  In any way, I don't think I've seen any
> references to that option anywhere.
>   
Maybe you missed it or you are using a lxc version < 0.6.3.
It should be the last line of the output of lxc-checkconfig in the 
'Misc' section.

The man page of lxc gives the requirement for the kernel:

...

REQUIREMENTS
       The  lxc  relies on a set of functionalies provided by the kernel 
which needs to be active. Depending of the missing functionalities
       the lxc will work with a restricted number of functionalities or 
will simply fails.

       The following list gives the kernel features to be enabled in the 
kernel to have the full features container:

                * General setup
                  * Control Group support
                    -> Namespace cgroup subsystem
                    -> Freezer cgroup subsystem
                    -> Cpuset support
                    -> Simple CPU accounting cgroup subsystem
                    -> Resource counters
                      -> Memory resource controllers for Control Groups
                  * Group CPU scheduler
                    -> Basis for grouping tasks (Control Groups)
                  * Namespaces support
                    -> UTS namespace
                    -> IPC namespace
                    -> User namespace
                    -> Pid namespace
                    -> Network namespace
                * Security options
                  -> File POSIX Capabilities
...

> So here it goes, if not only for reference so that others who will
> come to this issue in the future will know what to do.
>   

Thanks.
  -- Daniel
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers