In the case the container has a console with a valid slave pty file descriptor
we duplicate std{in,out,err} to the slave file descriptor so console logging
works correctly. When the container does not have a valid slave pty file
descriptor for its console and is started daemonized we should dup to
/dev/null.
Closes#1646.
Signed-off-by: Li Feng <lifeng68@huawei.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This adds a little more flexibility to the state server. The idea is to have a
command socket function "lxc_cmd_add_state_client()" whose only task is to add
a new state client to the container's in-memory handler. This function returns
either the state of the container if it is already in the requested state or it
will return the newly registered client's fd in one of its arguments to the
caller. We then provide a separate helper function "lxc_cmd_sock_rcv_state()"
which can be passed the returned client fd and listens on the fd for the
requested state.
This is useful when we want to first register a client, then send a signal to
the container and wait for a state. This ensure that the client fd is
registered before the signal can have any effect and can e.g. be used to catch
something like the "STOPPING" state that is very ephemeral.
Additionally we provide a convenience function "lxc_cmd_sock_get_state()" which
combines both tasks and is used in e.g. "lxc_wait()".
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Add a test to see if we can start daemonized containers that have a very
short-lived init process. The point of this is to see whether we can correctly
retrieve the state.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Since we killed lxc-monitord we rely on the container's command socket to wait
for the container. This doesn't work nicely on daemonized startup since a
container's init process might be something that is so short-lived that we
won't even be able to add a state client before the mainloop closes. But the
container might still have been RUNNING and executed the init binary correctly.
In this case we would erroneously report that the container failed to start
when it actually started just fine.
This commit ensures that we really all cases where the container successfully
ran by switching to a short-lived per-container anonymous unix socket pair that
uses credentials to pass container states around. It is immediately closed once
the container has started successfully.
This should also make daemonized container start way more robust since we don't
rely on the command socket handler to be running.
For the experienced developer: Yes, I did think about utilizing the command
socket directly for this. The problem is that when the mainloop starts it may
end up end accept()ing the connection that we want
do_wait_on_daemonized_start() to accept() so this won't work and might cause us
to hang indefinitely. The same problem arises when the container fails to start
before the mainloop is created. In this case we would hang indefinitely as
well.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
It is not necessary to unlink the abstract socket pathname when
we have finished using the socket. The abstract name is automatically
removed when the socket is closed.
Signed-off-by: Long Wang <w@laoqinren.net>
This patch allows users to start containers in AppArmor namespaces.
Users can define their own profiles for their containers, but
lxc-start must be allowed to change to a namespace.
A container configuration file can wrap a container in an AppArmor
profile using lxc.aa_profile.
A process in an AppArmor namespace is restricted to view
or manage only the profiles belonging to this namespace, as if no
other profiles existed. A namespace can be created as follow:
sudo mkdir /sys/kernel/security/apparmor/policy/namespaces/$NAMESPACE
AppArmor can stack profiles so that the contained process is bound
by the intersection of all profiles of the stack. This is achieved
using the '//&' operator as follow:
lxc.aa_profile = $PROFILE//&:$NAMESPACE://unconfined
In this case, even the guest process appears unconfined in the
namespace, it is still confined by $PROFILE.
A guest allowed to access "/sys/kernel/security/apparmor/** rwklix,"
will be able to manage its own profile set, while still being
enclosed in the topmost profile $PROFILE:
Different guests can be assigned the same namespace or different
namespaces. In the first case, they will share their profiles.
In the second case, they will have distinct sets of profiles.
This is validated on privileged containers.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@collabora.com>
This patch mainly update the message format to:
* upper the first letter
* end without a dot
all changes are relate to `lxc-init`
Signed-off-by: Long Wang <w@laoqinren.net>
