inside the container or the container does not have a working
nsswitch mechanism.
</para>
+ <para>
+ Previous versions of <command>lxc-attach</command> simply attached to the
+ specified namespaces of a container and ran a shell or the specified
+ command without allocating a pseudo terminal. This made them vulnerable to
+ input faking via a TIOCSTI <command>ioctl</command> call after switching
+ between userspace execution contexts with different privilegel levels. Newer
+ versions of <command>lxc-attach</command> will try to allocate a pseudo
+ terminal master/slave pair and attach any standard file descriptors which
+ refer to a terminal to the slave side of the pseudo terminal before
+ executing a shell or command. <command>lxc-attach</command> will first try
+ to allocate a pseudo terminal in the container. Should this fail it will try
+ to allocate a pseudo terminal on the host before finally giving up. Note,
+ that if none of the standard file descriptors refer to a terminal
+ <command>lxc-attach</command> will not try to allocate a pseudo terminal.
+ Instead it will simply attach to the containers namespaces and run a shell
+ or the specified command.
+ </para>
</refsect1>
except for the <replaceable>/proc</replaceable> and
<replaceable>/sys</replaceable> filesystems.
</para>
+ <para>
+ Previous versions of <command>lxc-attach</command> suffered a bug whereby
+ a user could attach to a containers namespace without being placed in a
+ writeable cgroup for some critical subsystems. Newer versions of
+ <command>lxc-attach</command> will check whether a user is in a writeable
+ cgroup for those critical subsystems. <command>lxc-attach</command> might
+ thus fail unexpectedly for some users (E.g. on systems where an
+ unprivileged user is not placed in a writeable cgroup in critical
+ subsystems on login.). However, this behavior is correct and more secure.
+ </para>
</refsect1>
<refsect1>