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

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

[Michael Tokarev]

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.

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!

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

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

[Daniel Lezcano]

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