Signed-off-by: RicardoSanchezA <ricardo.sanchez@utexas.edu>

lxc_init.c should not depend on tools/arguments.{c,h}, thus it needs its own custom argument parser
Signed-off-by: RicardoSanchezA <ricardo.sanchez@utexas.edu>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

lxc_init.c is actually not a tool, thus it doesn't belong to the tools/ subfolder
Signed-off-by: RicardoSanchezA <ricardo.sanchez@utexas.edu>

It doesn't make sense to error out when an app container doesn't pass explicit
arguments through c->start{l}().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Callers can then make a decision whether they want to consider the peer closing
the connection an error or not. For example, a c->wait(c, "STOPPED", -1) call
can then consider a ECONNRESET not an error but rather see it - correctly - as
a container exiting before being able to register a state client.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

This is the proper way to handle errors.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

If timeout is set to 0 don't block.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Take the lock on the list after we've done all necessary work and check state.
If we are in requested state, do cleanup and return without adding the state
client to the state client list.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

This checks whether multiple concurrent waiters all get notified by the state
server.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

- setting the handler->state value is atomic on any POSIX implementation since
  we're dealing with an integer (enum/lxc_state_t)
- while the state clients are served it is not possible for lxc_set_state() to
  transition to the next state anyway so there's no danger in moving to the
  next state with clients missing it
- we only care about the list being modified
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

There are multiple reasons why this is not required:
- every command is transactional
- we only care about the list being modified not the memory allocation and
  other costly operations
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

We're dealing with an integer (lxc_state_t which is an enum). Any POSIX
implementation makes those operations atomic so there's not need in locking
this.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

When we remove a state client fd there's not reason to walk the whole list. We
can simply break once we found and removed the fd.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

We want the loglevel that the user specified when starting the container
because it overrides the default one set in the config.

Closes #2003.
Reported-by: Felix Abecassis <fabecassis@nvidia.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

The arguments.{c,h} file should not be a part of liblxc itself. It should only
be used for the lxc tools.
Signed-off-by: RicardoSanchezA <ricardo.sanchez@utexas.edu>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

The lxc_log args have noghing to do with lxc.rootfs.path, and
we need room for a NULL at end of arguments.

How this bug was hidden for so long I don't know - I can only
trigger it on certain systems under certain conditions, but it's
definately wrong as is.
Signed-off-by: Serge Hallyn <shallyn@cisco.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Closes #1993.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Pierre LALET <pierre.lalet@cea.fr>

Signed-off-by: Pierre LALET <pierre.lalet@cea.fr>

- Backing Store types are hard-coded (Not sure how to get programmatically)
- Closes #1236
Signed-off-by: Abbas Ally <abbasally5@yahoo.com>

I followed the [changelog of Slackware-current]<http://www.slackware.com/changelog/>,
and found that Slackware-current split hostname utility from util-linux package in Nov 17 2017.
So I add the new package to the template.
Signed-off-by: Chia-Chun Hsu <a12321aabb@gmail.com>

Closes https://github.com/lxc/lxc/issues/1928Signed-off-by: i.Dark_Templar <darktemplar@dark-templar-archives.net>

Change conf.c to export function write_id_mapping, which will now be
called inside main function of lxc_unshare.c.

This is required because setuid syscalls only permits a new userns to
set a new uid if the uid of parameter is mapped inside the ns using
uid_map file[1]. So, just after the clone invocation, map the uid passed as
parameter into the newly created user namespace, and put the current uid
as the ID-outside-ns. After the mapping is done, setuid call succeeds.

Closes: #494

[1] https://elixir.free-electrons.com/linux/latest/source/kernel/user_namespace.c#L286Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

In addition to the memory corruption fixed in ee3e84df,
this function was also performing invalid memory accesses for the following inputs:
- `lxc.net`
- `lxc.net.`
- `lxc.net.0.`
- `lxc.network`
- `lxc.network.0.`
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>

This prevent an infinite recursion in the case of "lxc.net.0. = a"
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>

This caused the linked list of appenders to loop on itself, creating
an infinite logging loop in `__lxc_log_append`.
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>

Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>

Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>

Signed-off-by: AustinReichert <austinskyreichert@utexas.edu>

Signed-off-by: AustinReichert <austinskyreichert@utexas.edu>

Signed-off-by: AustinReichert <austinskyreichert@utexas.edu>