Bug#249496: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249496

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

follow-up, i found some references to dpkg and postinst.d:

	http://lists.debian.org/debian-dpkg/2002/03/msg00154.html
	http://lists.debian.org/debian-devel/2002/03/msg02063.html

the first thread gets a "THANK YOU! THANK YOU!" from one
person, and wichert raises the question of error messages
(from postinst.d scripts' exit codes) and somehow russell's
response is considered unsatisfactory and wichert declares
that he doesn't like SE/Linux, and that seems to be the end
of it.

[wichert, and others: please see ASF charter, summary of which
 is "mutual respect" and "assess on technical merits" although i
 personally believe that "assess on strategic merits" should
 also be included in that]


the second thread mentions an alternative scheme - a new
package dependency called "affects":

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=35691

the basis for recommending "affects" is best illustrated by the
mime-support package, whereby other (unlimited and unspecified)
packages must "register" with the mime-support package that
they handle certain file types.  the thing is that mime-support
is an optional package with no _actual_ dependency on the
packages that it supports.

at present, if you installed packages _after_ installing
mime-support these additional packages would not _get_ any
mime-support because the mime-support package had already
been configured.

now, a similar situation exists with the debian "menu"
system, except that that has been solved by providing
an update-menus script, and the support for update-menus
has been integrated whole-sale into packages:

	grep "update-menus" /var/lib/dpkg/info/* | wc

	gives a staggering 367 occurrences of "update-menus"
	in postrm and postinst scripts, out of 1788 such
	files.
	
on a sample of one [dodgy] debian/unstable system, a staggering
TWENTY PERCENT of all debian packages call the update-menus
script.

anyway.

so, the purpose of "affects" is to make a package re-run its
"postinst" script.

for example, if say lynx has an "affects" dependency on mime-support,
then when the lynx package registers that it deals with "*.html",
the mime-support "postinst" script will be called in order to
actually _register_ that.

now, you _could_ rewrite mime-support and all packages that
do mime to do the same sort of thing as update-menus - have
an update-mime-support script and manually have every single
package that registers mime support call update-mime-support
(if it exists).

the similarity between the two approaches is striking, yet
one approach is generic and the other is not.

in my mind, it's a hell of a lot better to add "affects" because
you just "name" the mime-support package and you get the
mime-support postinst script to cope with being called several
times.

in my mind, also, it would be a lot cleaner to remove the usage
of update-menus from all packages and to add an "affects" on
"menus", likewise.

causing TWENTY PERCENT of all package maintainers to have to have:

	if [ -x "`which update-menus 2>/dev/null`" ]; then update-menus ; fi

or: 

	if [ "$1" = "configure" ] && [ -x /usr/bin/update-menus ]; then
		update-menus ; fi

or other is just... INSANE!


... but, and it's a really important digression, i digress.

back to postinst.

"affects" could be used to achieve the same thing for SE/Linux.
... but think about it.  how many packages would require
the new dependency "affects" on selinux-policy-default?

	ABSOLUTELY ALL OF THEM.

i'll repeat that again.  EVERY SINGLE DEBIAN PACKAGE would require
"affects": selinux-policy-default.

why is this?  well, as mentioned before, it's because when you
install selinux, you have to install the files of a package and then
you have to set the security context on all of those files.

if you do not do this, you end up with a (null) security context
and users CANNOT ACCESS THAT FILE without intervention from
the system administrator.

therefore, if you do not set the security context, your system becomes
completely unusable.

it's a bit like all files being chmodded 000 and chowned to root,
and the users being expected to go around chmodding the filesystem
to the correct permissions etc.

that way lies chaos - and you might as well expect people to
accept a DOS FAT32 filesystem while you're at it.


the alternatives are:

1) you make all package maintainers responsible for setting SE/Linux
   file security contexts.

   this option has already been discussed and dismissed because
   not every package maintainer is going to know of the subtle
   interactions with his dependent packages, and they WILL get it
   wrong, with disastrous consequences.

2) you provide something like update-menus (e.g. update-selinux-context)
   but remember that it needs to go into EVERY package!!!!!

3) you provide something like "affects" but remember it needs to
   be added to EVERY package!!!

4) you patch dpkg and hard-code into dpkg itself a call to
   update-selinux-context.

5) you accept that the postinst.d patch is an extremely elegant way
   of achieving 4) in a generic way that separates and segregates
   the responsibility for SE/Linux from dpkg.

6) you make the linux kernel responsible, somehow, on every single
   file create, for setting SE/Linux file security contexts as
   looked up in the file_contexts "map" which is a massive and
   unworkable undertaking that would in no way be accepted by any
   sane kernel developer except if this was microsoft of course
   who even tried to move thousands of third party printer drivers
   into the nt kernel and they backed out of THAT one pretty
   damn quickly.


basically what i am coming round to demonstrating is that the
postinst.d patch is about the only sane way to do this.

- you CANNOT expect every single maintainer to call an
  update-selinux-context script

- you CANNOT expect to hard-code a call to update-selinux-context
  into dpkg (well, you can, but i certainly wouldn't accept it)

- you CANNOT expect every single package to have an "affects"
  dependency on selinux-policy-default

- you CANNOT ask any sane linux kernel developers to accept a
  massive kernel-space performance hit when a user-space solution
  already exists

therefore the only viable option that i can think of is the one
developed by russell, and it works, _and_ rpm has a similar
scheme already in place, _and_ it's coded up already, _and_ it's
already in use on Debian / SE/Linux systems.

the only thing that you have to watch out for is that other
package maintainers don't abuse it: that can be dealt with by
writing an appropriate Debian Policy section to describe the
circumstances under which it should be used.

update-menus comes pretty close to being one of the few systems
that could benefit from being converted to postinst.d instead.

if people object to having an extra few seconds
added onto packages that don't have menus, then an
/etc/dpkg/postinst.d/menu script could background the
update-menus update.  although, to be honest, "affects"
_would_ be a lot better for update-menus, as already
outlined.


summary: the alternative approaches leave postinst.d as the
         only viable option.  it will be necessary to ward
		 people off from abusing postinst.d, possibly by
		 implementing "affects".

l.

p.s. http://www.advantix.org (rsbac.org) could likely benefit
from postinst.d.


-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<a href="http://lkcl.net";>      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net";> lkcl@lkcl.net </a> <br />