On 12/11/2012 02:51 PM, Josh Boyer 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. >> >> 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? > > I think you're on your own as the kmod maintainer on this one, Lucas. > Jon is rather busy and hasn't commented on this in 2.5 years. I don't > think waiting around for him to do so now is going to serve anyone's > best interests at this point. All true points :) But specifically on why whitelisting didn't happen, because it was contentious and the approach of just having a whitelist file wasn't going to scale. That would mean that a new kernel changing the name of a driver or adding a new driver, or even buying some new hardware would require updates to the whitelist files. I understand this is something that some very security sensitive folks want to do, but I don't personally feel a whitelist is the way to achieve it. However, I'll let you guys solve this one :) Jon. -- 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
