[lxc-devel] [PATCH] lxc-attach: elevate specific privileges

[Christian Seiler]

Hi there,

> And if you have a bit of time I'd appreciate if you could explain why
> should we elevate privileges for attaching to specific namespace? 
> Seems
> to me that it is unrelated, since I should be able to enter NETWORK 
> ns
> while not elevating cgroup, for example?

Since I added those options back in the day, a bit of a rationale:

If I run lxc-attach without any further options, my expectation is that
the process spawned sees nothing different compared to a process
spawned from within the container. This is the case.

Now if I specify that I only want to attach to the network namespace,
then the spawned process is in a weird state: mount, pid, user, ipc and
uts namespaces are all still those of the host, but the network
namespace now is different. In some sense this already implies that the
privileges of that process are 'elevated' compared to the privileges of
a process in the container - it has access to the host in the other
namespaces. For this reason, moving that process into the cgroup,
dropping capabilities and loading the corresponding LSM context seem
out of place, for this reason, I made -s imply -e.

However, with your patch (which makes sense since my rewrite of the
API), I think one could give the user the option of not evelating the
other privileges. And while I do think that because of the above
rationale having elevation being the default state when using -s, what
do you think of the following proposal?

  - default => all privs dropped
  - only -s specified => no privs dropped
  - -e specified without argument => no privs dropped
  - -e NONE specified (regardless of -s) => all privs dropped
  - -e ALL specified (regardless of -s) => no privs dropped
  - -e A|B|C specified (regardless of -s) => A, B and C privs elevated,
                                             the rest dropped

What do you (and Stephane and Serge) think?

-- Christian