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. josh -- 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
