<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On Thu, 23 May 2019 16:27:00 +0000 Dmitry Bogatov <kaction@debian.org>
wrote:<br>
> <br>
<jsmith@resonatingmedia.com>> <br>
> Also, every WITH_FOO flag doubles number of configurations
your program<br>
> have. Once you have dozen of flags, you no longer can test
all of<br>
> configurations.<br>
<br>
Why not?<br>
<br>
> <br>
> I am surprised, that there is so much controversy on
whether it is good<br>
> to have some feature of program pluggable without
re-compilation. The<br>
> only real concern that was raised, as I see it, is how
SELinux interacts<br>
> with extra fork/exec.<br>
</jsmith@resonatingmedia.com></kaction@debian.org><br>
The proposed patch doesn't seem to make the feature pluggable, it
just moves the feature to a second binary. There isn't anything here
which toggles the feature on/off, or lets the admin enable/disable
it.<br>
<br>
That being said, I'd be open to applying this upstream, with four
conditions or changes:<br>
<br>
1. The selinux-check binary should probably be renamed so it is
clear this program is part of the SysV init suite. Maybe calling it
something like /sbin/sysvinit-selinux-check? I'm open to suggestions
as to what it should be called.<br>
<br>
2. The patch should respect the compile-time define WITH_SELINUX in
both init.c and in the check-selinux.c code. Otherwise the build
will either fail or attempt to perform unnecessary fork/exec on
systems without SELinux, like Hurd and kFreeBSD. In fact, the
Makefile should skip building & installing check-selinux.c
completely if SELinux is not available on that platform. Otherwise
we are making things more resource hungry and complex on systems
where SELinux is not included, rather than less.<br>
<br>
3. The new binary/helper program should have a man page.<br>
<br>
4. There should be a test or script presented that demonstrates
SELinux still works properly with this approach. I don't want to
open a security issue by moving SELinux support to a non-PID1
binary.<br>
<br>
<br>
</body>
</html>