<p>On Sat, 30 Apr 2011 18:44:13 +0200, Kay Sievers wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>On Sat, Apr 30, 2011 at 02:54, Lennart Poettering <<a href="mailto:mzerqung@0pointer.de">mzerqung@0pointer.de</a>> wrote:<br /><blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">On Fri, 29.04.11 17:46, Greg KH (<a href="mailto:greg@kroah.com">greg@kroah.com</a>) wrote:<br /><br /><blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">I think /srv actually makes a lot of sense. Probably not so much on the<br />desktop, but the boundaries are blurry, and I see no reason to set<br />things up differently in this respect between servers and desktops. I<br />see little benefit in removing this directory.<br /><br /></blockquote>I think moving /selinux is a bit more complicated then just a simple<br />kernel change. We have libselinux changes, Lots of tools have learned<br />over the years the path of /selinux and lots of users know about it.<br /><br />I am willing to work towards the goal of moving /selinux, but I might<br />end up with a symbolic link if we can not fix all of the problems.<br /></blockquote><br />A symbolic link from /selinux to point at /sys/fs/selinux/ is a good<br />idea to help people migrate. The startup tools should be able to create<br />this if /sys/fs/selinux/ is not present, right?<br /></blockquote><br />This is not necessarily easy to do actually, since for upgraded systems<br />/selinux needs to be an actual directory in the rootfs to be useful as<br />mount points. At boot time the rootfs is read-only, hence removing the<br />dir then and turning it into a symlink is difficult.<br /><br />However, we can use the same approach as we did for moving /var/run to<br />/run: on new installs create it as a symlink and on upgrades simply make<br />it a bind mount.<br /><br />For the long run we could also add %post scripts to filesystem.rpm which<br />moves away the old /selinux, and recreates it as symlink. Unfortunately<br />that cannot be done completely atomic, but that property is not really<br />necessary here anyway I think.<br /><br />So, yeah, it isn't super-pretty doing this move, but we can handle it<br />more or less exactly like the /var/run → /run move.<br /></blockquote><br />Sounds all fine. I think we should get the kernel patch merged as soon<br />as possible. It will not harm anything if we don't use it now, and<br />continue to use /selinux as long as needed. But it will definitely<br />help solving the chicken egg problem when we are ready to do the<br />switch.<br /><br />Kay</pre>
</blockquote>
<p>Resending since I sent from the wrong email address and devel rejected it.</p>
<p>Merging the kernel patch without doing the legwork for userspace first is a very bad idea. The kernel is what mounts the FS under /selinux so if you have it mount under /sys/fs/selinux instead without coordinating with the required usespace changes you'll have a completely broken system. I'd say let Dan handle when the right time to merge the kernel patch is since both him and the tresys people will have to be involved with releasing new versions of libselinux . Also Dan will have to work with some of the package maintainers to cleanup and fix their packages as well. I'd really not like it if I can't test new kernels with my labeled-nfs patches because we merged an ABI breaking change into mainline without making sure people can handle it first.</p>