[systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?

[David Quigley]

On Sat, 30 Apr 2011 18:44:13 +0200, Kay Sievers wrote: 

> On Sat,
Apr 30, 2011 at 02:54, Lennart Poettering wrote:
>> On Fri, 29.04.11
17:46, Greg KH (greg at kroah.com [1]) wrote:
>> 
>>>>> I think /srv
actually makes a lot of sense. Probably not so much on the
>>>>>
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.
>>>> I think
moving /selinux is a bit more complicated then just a simple
>>>> 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.

Links:
------
[1] mailto:greg at kroah.com
[2]
mailto:mzerqung at 0pointer.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110502/3ae8eacf/attachment.html