Bug#249496: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249496
On Sat, May 29, 2004 at 10:32:05PM -0300, Scott James Remnant wrote:
> On Sat, 2004-05-29 at 21:46 +0000, Luke Kenneth Casson Leighton wrote:
> > i'm doing a status report on the progress of Debian SE/Linux
> > support.
> > i'm aware that the postinst.d patch is well-known, shall we say.
> > what news can i put into the status report?
> The patch hasn't been accepted, any dpkg triggers support needs to be
> complete and full-featured and not a temporary hack.
oh. right. um, okay.
so that's related to the other reports, like #17243 etc., yes?
so, on the one hand, i am puzzled, because i feel that the ethos
of "little and often" increments, especially when contributed from
several people, makes for continuous progress: how can someone
with only a few spare hours contribute another part of the larger
picture unless they have some of the pieces to cut/paste?
on the _other_ hand, i realise that this is quite a significant
addition to dpkg functionality, that it may not fit with what
may have already been discussed as the way forward: consequently,
what may end up in dpkg might not necessarily be a postinst.d
this makes things slightly awkward. SE/Linux needs the
postinst.d thing, or equivalent, _now_ not later, because the
files listed in any package being installed _must_ have their
SE/Linux security permissions set, and it is unreasonable to
expect each and every package to be modified to perform that
consequently, anyone wishing to use SE/Linux on Debian must
continue to download a separately maintained and
non-debian-mainline-controlled dpkg, from
http://selinux.lemuria.org/newselinux/dpkg, and if they don't
install that version, they can expect their system to break
whenever they install a new package, or to have to manually
run "setfiles" - the file security setting program - themselves.
not that i'm twisting your arm or anything: i'm just outlining
logically, objectively and without prejudice what the knock-on
effects of the decision not to accept that patch are.
[i don't know anything about you, so i don't know if you'll
be offended by this approach: i'd appreciate knowing that
you don't intend to shoot the messenger :) ]
the workarounds are to have the linux kernel do it,
at file create time, to store the security file_contexts "map"
somewhere in the kernel.
or to have a user-space trigger on each and every single file
create that runs the setfiles program.
neither of these two are really viable options: adding stuff
to the linux kernel, especially when the security file_contexts
"map" can be extremely large... ... and running a user-space
trigger on _every_ file create just in case it _might_ be in
the file_contexts map? naaah :)
1) postinst.d patch not yet accepted upstream as it's one
part of a larger picture that hasn't been finalised.
2) therefore people using Debian/SELinux must at present
use a separately maintained dpkg.
3) workarounds involving the kernel are not viable.
therefore, it necessary to get whatever plans for a
postinst.d replacement / equivalent in place and working
1) where can i find information / references to plans and
discussions on postinst.d equivalent functionality?
2) is there a functional specification already outlined
that i can quickly implement?
3) if there isn't a functional specification already
outlined, whom can i approach to encourage them to
4) if neither 2) nor 3) works, what would it take to
persuade people that postinst.d will "do the job",
it's not what might have been originally envisaged,
but it's "close enough", and more importantly, it's
actually been implemented (whereas #17243 wishlist
item dates back SIX YEARS to 1998!)
5) who else can i chase with a Big Stick?
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
*blink*. oh, it's a .sig. :)