Fix typo in lxc_attach's usage

Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
doc: Update Japanese lxc-snapshot(1) for adding the description of destroy

Update for commit 18aa217

Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
don't force dropping capabilities in lxc-init

Commit 0af683cf added clearing of capabilities to lxc-init, but only
after lxc_setup_fs() was done, likely so that the mounting done in
that routine wouldn't fail.

However, in my testing lxc_caps_reset() wasn't really effective
anyway since it did not clear the bounding set. Adding prctl
PR_CAPBSET_DROP in a loop from 0 to CAP_LAST_CAP would fix this, but I
don't think its necessary to forcefully clear all capabilities since
users can now specify lxc.cap.keep = none to drop all capabilities.

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
allow lxc.cap.keep = none

Commit 1fb86a7c introduced a way to drop capabilities without having to
specify them all explicitly. Unfortunately, there is no way to drop them
all, as just specifying an empty keep list, ie:

    lxc.cap.keep =

clears the keep list, causing no capabilities to be dropped.

This change allows a special value "none" to be given, which will clear
all keep capabilities parsed up to this point. If the last parsed value
is none, all capabilities will be dropped.

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
split -lcap and -lselinux out of LIBS

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
fix the expansion of libexecdir when not explicitly passed to configure

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
seccomp: support 'all' arch sections (plus bugfixes)

seccomp_ctx is already a void*, so don't use 'scmp_filter_ctx *'

Separately track the native arch from the arch a rule is aimed at.

Clearly ignore irrelevant architectures (i.e. arm rules on x86)

Don't try to load seccomp (and don't fail) if we are already
seccomp-confined.  Otherwise nested containers fail.

Make it clear that the extra seccomp ctx is only for compat calls
on 64-bit arch.  (This will be extended to arm64 when libseccomp
supports it).  Power may will complicate this (if ever it is supported)
and require a new rethink and rewrite.

NOTE - currently when starting a 32-bit container on 64-bit host,
rules pertaining to 32-bit syscalls (as opposed to once which have
the same syscall #) appear to be ignored.  I can reproduce that without
lxc, so either there is a bug in seccomp or a fundamental
misunderstanding in how I"m merging the contexts.

Rereading the seccomp_rule_add manpage suggests that keeping the seccond
seccomp context may not be necessary, but this is not something I care
to test right now.  If it's true, then the code could be simplified, and
it may solve my concerns about power.

With this patch I'm able to start nested containers (with seccomp
policies defined) including 32-bit and 32-bit-in-64-bit.

[ this patch does not yet add the default seccomp policy ]

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>