
Cc's and subject updated so hopefully we get the correct people
on this discussion to make progress..
That is an interesting viewpoint on what is not complete. But as a
listing of the tasks that distribution startup needs to do differently in
a container the list seems more or less reasonable.
There are two questions
- How in the general case do we detect if we are running in a container.
- How do we make reasonable tests during bootup to see if it makes sense
to perform certain actions.
For the general detection if we are running in a linux container I can
see two reasonable possibilities.
- Put a file in / that let's you know by convention that you are in a
linux container. I am inclined to do this because this is something
we can support on all kernels old and new.
- Allow modification to the output of uname(2). The uts namespace
already covers uname(2) and uname is the standard method to
communicate to userspace the vageries about the OS level environment
they are running in.
My list of things that still have work left to do looks like:
- cgroups. It is not safe to create a new hierarchies with groups
that are in existing hierarchies. So cgroups don't work.
- user namespace. We are very close to have something workable
on this one, but until we do all of the users inside and outside
of a container are the same, and pass the same permission checks.
As a result we have to drop most of roots privileges, and we have
to be a bit careful what binaries that can gain privileges (think suid
root) are in the container filesystem.
- Reboot. I know Daniel was working on something not long ago
but I am not certain where he would up.
- device namespaces. We periodically think about having a separate
set of devices and to support things like losetup in a container
that seems necessary. Most of the time getting all of the way
to device namespaces seems unnecessary.
As for tests on what to startup.
-.
- VTs. Ptys should be well supported at this point. For the rest
they are physical hardware that a container should not be playing with
so I would base which gettys to start up based on which device nodes
are present in /dev.
-.
- audit. My memory is very fuzzy on this one. The issue in question is
should we start auditd? I believe the audit calls actually fail in a
container so we should be able to trigger starting auditd on if audit
works at all. If we can't do it that way certainly the work should be
put in so that it can be done that way.
- fsck. A rw filesystem check like you mentioned earlier seems like a
reasonable place to be I know the OpenVz folks were talking about
putting containers in their own block devices for their next round of
supporting containers. At which point a filesystem check on container
startup might not be a bad idea at all.
- cgroups hierarchies. I don't know at which point in the system
startup we care. The appropriate solution would seem to be to try
it and if the operation fails figure it isn't supported.
-.
In general things in a container should work or the kernel feature
should fail in a way that indicates that the feature is not supported.
That currently works well for the networking stack, and with the
pending usablilty of the user namespace it should work just about
everywhere else as well. For things that don't fit that model we
need to fix the kernel.
So while I agree a check to see if something is a container seems
reasonable. I do not agree that the pid namespace is the place to put
that information. I see no natural to put that information in the
pid namespace.
I further think there are a lot of reasonable checks for if a
kernel feature is supported in the current environment I would
rather pursue over hacks based the fact we are in a container.
Eric
Linux is a registered trademark of Linus Torvalds