Hi Josh, On Thu, Mar 21, 2013 at 10:21 AM, Josh Boyer <jwboyer@xxxxxxxxx> wrote: > On Tue, Nov 6, 2012 at 1:43 PM, Lucas De Marchi > <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >> CC'ing Jon Masters >> >> On Tue, Nov 6, 2012 at 3:59 PM, Josh Boyer <jwboyer@xxxxxxxxx> wrote: >>> On Tue, Nov 6, 2012 at 12:50 PM, Lucas De Marchi >>> <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >>>>> It seems to be about giving admins more control over which modules can >>>>> be loaded, particularly in the presence of hotplug mechanisms that can >>>>> auto-load drivers for various devices when they're plugged in. >>>> >>>> then how is this any better than a whitelist in which modules get installed? >>> >>> Well, I didn't say it was. However, from a distribution perspective >>> you can do one of the following with a common distribution kernel RPM: >>> >>> 1) Install kernel RPM; remove modules from /lib/modules after the fact. >>> 2) Code something into the RPM %post script that looks at a whitelist >>> on the machine and automatically removes modules not in that list >>> after the install (really a refinement of option 1). >>> 3) Blacklist every module except those you want to allow to be loaded >>> (opposite of the proposed solution). >>> 4) Add a whitelist to kmod. >>> 5) Something I haven't thought of. >>> >>> Option 1 is kind of ugly to have to do by hand. Option 2 is slightly >>> more feasible. Both of them would then cause RPM's idea of what a >>> package provides to be somewhat broken though (e.g. rpm -V would fail). >>> >>> Option 3 is fairly tedious to do by hand for a sysadmin. >>> >>> Option 4 is what has been proposed. It has positives and negatives >>> and I'm sure that is what Milan is looking to discuss so I'll leave >>> that be. >>> >>> Option 5 is clearly beyond my capacity of thinking at the moment ;). >>> >>> So, there are multiple ways to solve this. I just wanted to make sure >>> the proposed option wasn't being viewed as a lock-in mechanism. >> >> Ok. I kind of see the point here. I was worried about the arguments >> for it though. > > Reviving an old thread here... > > Lucas, did you decide on whether or not this functionality was acceptable > upstream? If so, I can repost the patch against latest git. There are > security minded people that would like to see this available, and given > that it is entirely optional I don't see much in the way of burden. I > can make a note that people will need to be diligent in maintaining their > whitelist if they use one. > > Let me know how you want to proceed. I'm no huge fan of this feature. Indeed I think it's a pretty broken feature (just not as broken as the install rules we need to carry for compatibility reasons). I also think that for people that needs this a custom kernel with things compiled-in would be way better. That said, I will give you guys the opportunity to shoot yourselves on the foot. Please rebase the patch. I'm sending another email commenting on somethings I'd like to see in this patch before applying. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
