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. Jon, it seems it was a feature request for module-init-tools ~ 2.5 years ago. Any reason why it was not accepted back then? 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
