dazuko-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dazuko-devel] container support in DazukoFS


From: John Ogness
Subject: [Dazuko-devel] container support in DazukoFS
Date: Sat, 03 Jul 2010 12:57:10 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

[Cc: Eric Biederman because of his container feedback on LKML.
 Hi Eric, the Dazuko-Devel mailing list is register-only, but if you
 reply to me, then I can post your comments on the list.]

Hi,

I've been wondering what we could do to make DazukoFS more acceptable
for mainline inclusion. Aside from making DazukoFS more complete:

http://lists.gnu.org/archive/html/dazuko-devel/2010-06/msg00000.html

the main issue reported from LKML reviews was that we need to support
containers. I think I have a solution for this, which will also make
DazukoFS more flexible when not using containers.

My idea is the following:

1. There is only 1 global device "/dev/dazukofs.ctrl".

2. When a group is added (using the "add" or "addtrack" commands),
DazukoFS will create the "/dev/dazukofs.N" group device within the
container-space of the process adding the group. This means that
contained environments can create their own local group devices. For
systems not using containers this is also an improvement because it
means group devices are created dynamically (instead of the 10 static
groups that exist now).

3. When a process reads the global control device to see the group
names, only the groups within the same container-space as the reading
process are shown. This keeps information about other containers
private.

4. When a file is accessed, only the groups from container-spaces
where the file exists in that container-space will be notified.

5. If an ignore device is desired, it may be created using a new
command for the control device. Perhaps something like "addign". The
ignore device would be created within the same container-space of the
process requesting the ignore device. The ignore scope would only be
the container-space of the ignore device. This means that if a process
is being ignored within its container, a non-contained process on the
host machine could still react to files accesses by the contained
ignored process.

6. When a new group is created, it does not go live until the first
read on the group device has occured. This allows an application to
setup a new group and set the permissions on the new group device
before dropping its privileges and beginning file access control.


There are a couple things that I like about these changes. First off,
I like that group and ignore devices are created dynamically. This
should have been the way it was done from the beginning. This not only
removes restrictions on the number of groups, but makes it much easier
to think in terms of containers.

Secondly, I like that a group does not go live until the first read on
the group device. This makes it much simpler (and cleaner) for
developing non-privileged applications to perform online file access
control.

I also see some open issues here. When automatically creating new
devices, one must always consider the permissions and ownership
involved. Right now this can be handled using udev rules or by a
privileged process setting them appropriately. I think that this is
probably ok for now, especially since complex SElinux rules could come
into play. But it is something we need to keep in mind.

I am not familiar with how udev works for containers. For example,
would every container be able to have its own /dev/dazukofs.0 or must
udev devices be globally unique? Either way, I do not see this as a
problem, but will need to be considered.

I am also not familiar with the kernel API's for container
management. So my idea may need to be adjusted a bit, but I think in
general it should work. If anyone has experience with containers, I'd
be interested in hearing about this.

John Ogness

-- 
Dazuko Maintainer



reply via email to

[Prev in Thread] Current Thread [Next in Thread]