On Sat, 30 Apr 2011 18:44:13 +0200, Kay Sievers wrote:
On Sat, Apr 30, 2011 at 02:54, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:On Fri, 29.04.11 17:46, Greg KH (greg@xxxxxxxxx) wrote:I think /srv actually makes a lot of sense. Probably not so much on theI think moving /selinux is a bit more complicated then just a simple
desktop, but the boundaries are blurry, and I see no reason to set
things up differently in this respect between servers and desktops. I
see little benefit in removing this directory.
kernel change. We have libselinux changes, Lots of tools have learned
over the years the path of /selinux and lots of users know about it.
I am willing to work towards the goal of moving /selinux, but I might
end up with a symbolic link if we can not fix all of the problems.
A symbolic link from /selinux to point at /sys/fs/selinux/ is a good
idea to help people migrate. The startup tools should be able to create
this if /sys/fs/selinux/ is not present, right?
This is not necessarily easy to do actually, since for upgraded systems
/selinux needs to be an actual directory in the rootfs to be useful as
mount points. At boot time the rootfs is read-only, hence removing the
dir then and turning it into a symlink is difficult.
However, we can use the same approach as we did for moving /var/run to
/run: on new installs create it as a symlink and on upgrades simply make
it a bind mount.
For the long run we could also add %post scripts to filesystem.rpm which
moves away the old /selinux, and recreates it as symlink. Unfortunately
that cannot be done completely atomic, but that property is not really
necessary here anyway I think.
So, yeah, it isn't super-pretty doing this move, but we can handle it
more or less exactly like the /var/run → /run move.
Sounds all fine. I think we should get the kernel patch merged as soon
as possible. It will not harm anything if we don't use it now, and
continue to use /selinux as long as needed. But it will definitely
help solving the chicken egg problem when we are ready to do the
switch.
Kay
Resending since I sent from the wrong email address and devel rejected it.
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.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
