Now we have seen what
per-process namespaces and
shared subtrees are and how to operate them, we can try to combine these two features.
We ll be using our
newns tool from this
earlier post to create new namespaces. And for practical reasons, let s say you have a terminal with a
1$ prompt and a second terminal with a
2$ prompt (that will allow me to skip go to the second terminal phrases).
In the kernel, per-process namespaces are a bit like bind mounts, such that shared subtrees work with namespaces like they do with bind mounts.
As with standard bind mounts, the default shared subtree mode is
private, which means mounts done on either namespaces will be private to the namespace. Only mount points active at the time of the new namespace creation will be in both namespaces:
1$ ./newns
1$ mount /dev/sda1 /mnt
1$ ls /mnt
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
2$ ls /mnt
2$ mount /dev/sda1 /cdrom
2$ ls /cdrom
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
1$ ls /cdrom
1$ umount /mnt
1$ exit # Exit from newns
2$ umount /cdrom
shared mode allows both namespaces to share subsequent mounts. As with bind mounts, and for obvious reasons, you need to change the subtree mode before creating the new namespace:
1$ mount --make-rshared /
1$ ./newns
1$ mount --bind /usr /mnt
1$ ls /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
2$ ls /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
Like with shared bind mounts, the new mount point can be unmounted from either namespace:
2$ umount /mnt
1$ ls /mnt
1$ exit # Exit from newns
A
slave subtree will have mount points under its master (shared) subtrees propagated, while propagation won t happen in the other direction. Again, very much like bind mounts:
1$ mount --make-rshared / # For completeness, we already did that earlier
1$ ./newns
1$ mount --make-rslave /
1$ mount --bind /usr /mnt
1$ ls /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
2$ ls /mnt
2$ mount --bind /usr /cdrom
2$ ls /cdrom
bin games include lib lib32 lib64 local sbin share src X11R6
1$ ls /cdrom
bin games include lib lib32 lib64 local sbin share src X11R6
1$ exit # Exit from newns
2$ umount /cdrom
Contrary to
shared and
slave,
unbindable doesn t add value when used in two different namespaces. This is only something that will have impact on the current namespace:
1$ mount --make-rshared / # For completeness, we already did that earlier
1$ ./newns
2$ mount --make-runbindable /
2$ mount --bind /usr /mnt
mount: wrong fs type, bad option, bad superblock on /usr,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg tail or so
1$ mount --bind /usr /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
1$ exit # Exit from newns
1$ mount --make-rprivate # Set back to default
Now we ve seen what can be done with namespaces and shared subtrees, let s see what nice features can be implemented with both.
As
Russell revealed, pam-namespace is able to polyinstanciate some directories following rules set in
/etc/security/namespace.conf (see
namespace.conf(5)). The sad thing is that it apparently can t just create a new namespace without polyinstanciating a directory, which could be useful if you only want separate namespaces, but no polyinstanciated directory.
Russell s recipe goes as follows:
- At boot time,
/ is put in shared mode and /tmp in private mode.
- When opening a session, pam will create a new namespace, and bind mount
/tmp-inst/$USER to /tmp.
What this means is that in the newly created namespace, a user reading in
/tmp will actually be reading in
/tmp-inst/$USER without the user knowing. Also, if root mounts something on the parent namespace, it will be propagated (
/ being
shared) to the user namespace. This means that mounting USB storage, for example, will be propagated to the user namespace. This also means that something mounted from the user namespace will also be propagated to the parent namespace. In both cases, this only applies to mounts occuring outside of
/tmp, for which mounts don t get propagated.
Note that without setting
/tmp as
private, when PAM would be mounting
/tmp/inst/$USER, it would propagate as well, setting
/tmp to
/tmp/inst/$USER for everyone. So setting
/tmp as
private is mandatory.
There is, however, a flaw in Russell s recipe: If any of the user mounts something under a submount of
/, under
/var for example, if
/var is mounted, it won t be mounted to a user that already had a session opened. For that to be possible, you have to use
--make-rshared instead of
--make-shared in Russell s recipe.
Some nice setup that can be done with all these, is the following:
Add the following to
/etc/security/namespace.conf:
/tmp tmpfs tmpfs root
Add the following to
/etc/pam.d/common-session:
session required pam_namespace.so
Until here, it is pretty much the same as Russell s, except
/tmp is a
tmpfs instead of a real directory in
/tmp-inst/, which can have some advantages. It doesn t seem to be possible to give pam-namespace a size for the
tmpfs, though.
Add the following to
/etc/rc.local:
mount --make-rshared /
mount --bind /tmp /tmp
mount --make-private /tmp
Here again, this is the same as Russell s except for the correction for
--make-rshared as seen above. If
/tmp is already a mount point (on my systems, it is a
tmpfs), you can remove
mount --bind /tmp /tmp from above.
Add the following to
/etc/security/namespace.init:
mount --make-rslave /
Now, this is where it gets interesting: we re setting the whole tree as
slave in the user namespace which means that if a user mounts a file system anywhere, it will only be seen in his session. Which means the user can more safely mount encrypted volumes: they won t be available to other users (root can still go wandering in
/dev/kmem, though). And you don t even need SE linux for that.
The caveat is that if you open a root session with su, from the user session, you are still inside the user boundaries, and don t have access to the virtual filesystem as it is for init. And if you mount something as root then, while it will appear in the user namespace, it won t appear neither in other users namespace nor in init s, which can be a good thing in some cases, but a burden in others. It means you may need to setup a special user that won t get a new namespace in
/etc/security/namespace.conf.
An alternative model would be to only set the user s home as
slave, which means anything mounted by the user in his home directory would stay private in his namespace, while anything mounted outside would be shared with other namespaces.
For that, you may want to replace the lines we added to
/etc/security/namespace.init with the following:
HOME=$(getent passwd $3 cut -d: -f6)
mount --bind "$HOME" "$HOME"
mount --make-rslave "$HOME"
Either way, the remaining problem is that a root session opened with su from the user session won t get access to the original
/tmp.
As we saw, there are various use cases for namespaces and shared subtrees. I ll follow-up again on these features soon, as I ll be using them in yet another way to achieve a very different purpose.
I went on IRC to ask a simple technical question earlier today. I
wasn't going to ask it in the #debian-devel channel, since it
was a samba question rather than a debian-related one; but since my IRC
client was still running, and had that channel active, I couldn't help
but notice some discussion about "what-ifs" when there isn't a
secretary, and who gets to do what then.
Surely this was idle speculation, I thought? But that can sometimes
be fun, so let's look at the backlog, and see...
That's when I found out that this wasn't,
in fact, idle speculation.
Oh dear.
Well, that's the end of an era, I guess. Not that it wasn't totally
unexpected; when I learned that Neil McGovern had become "assistant
secretary", I already suspected that Manoj was going to resign
eventually, and he does confirm that suspicion in his resignation email.
However, the suddenness of it certainly was unexpected.
Here's a tip of the hat for everything Manoj has done for Debian so
far. I can only wish to be at your level.
What does distress me, however, is a part of Manoj's email, in which
he mentions some people had been trying to get him kicked from the
project:
After two and half months of development, new 
Dell chose to ship Linux on the 
So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others.
SSD disk
I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it s the second generation of Samsung SSD) and I m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds.
X server
The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It s possible to force the usage of the intel driver by adding a Driver intel line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn t use the Keyboard section of xorg.conf. You have to create 
That is the sledgehammer argument people bring up when others dare to criticize the current release process.
I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we simply started the freeze with much more open RC-bugs than before (~3 times more RC-bugs than with Etch). So it was foreseeable that the freeze would take longer this time. We can t solve the problem by trying to fix bugs faster, we ve tried it several times with mediocre success. That doesn t mean we shouldn t keep up fixing bugs, but we should probably accept that a certain number of people can only fix a certain number of bugs in a given time. In our case roughly 30 RC-bugs per month.
So what s the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? That pressure doesn t help anyone. I believe unstable being frozen for several months is a very important problem which can have drastic consequences regarding the number of our users, and we will not solve it by suggesting to fix our bugs faster.
So, in the Membership Status GR, we sent a clear message that we wanted those decisions to be postponed. Now, we have a responsibility to prove that we were not just rejecting any change, but that our vote was really a vote against the way those decisions were announced, and/or those particular decisions. I m convinced that our management of membership needs to be improved.
I hope that in the next weeks/months, we will be able to discuss proposals about membership status. There s Joerg s, there s Lars , there s Raphael s, and there might be other ideas. Ideally, each of them would be discussed and improved separately (because we can t be expected to agree on one proposal right from the start), and finally we would get to vote on a coherent set of proposals (with an unbiaised ballot ;) to choose in which direction we want to change our management of membership. It would be great to use the DEP process or something similar for that.
It is also interesting to compare this whole story with our current issue: a secretary that ignored valid criticism about a ballot and went on with asking to vote on it. In both cases, someone that is generally trusted and respected by the project made a mistake, and failed to acknowledge it, requiring strong actions from other DDs. I wonder how the secretary crisis will end
Well, following some other posts on Planet debian, I decided to also publish my vote on the GR regarding Firmware blobs in Debian. Here is my vote:
It is sad to see how 
Regarding the ballot currently before the Developers, Christian
Perrier 
Travelling rather a lot this year has left me spending plenty of time staring at showers[1]. There seem to be three broad categories of shower UI design. The first is the one that exposes the raw functionality of the underlying implementation:
As