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. > > > Ok... > > > 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? okay. 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 solution. 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 action. 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 :) so. summary. 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 ASAP. so. 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 write one? 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? l. > Scott > -- > Have you ever, ever felt like this? > Had strange things happen? Are you going round the twist? YES. *blink*. oh, it's a .sig. :)
