Bruce Evans wrote: > > patch should do it as well as making pppd do the right thing when > > support isn't compiled in, but a module is available. It should make > > things work with a GENERIC kernel. > > I disagree with auto-loading of modules for anything, but especially in > setuid programs like pppd.
It's really tempting to say that modules should be classified by the services they can provide, and, barring them being disallowed, have the kernel automatically load them when the services they export are referenced, if they are not already loaded. Module code is trusted code, even if the people who might want to load modules into the kernel are not. Really, the security association that establishes the trust needs to trust the module code, not trust (or not trust) the user (IMO). The bset way to do this, I think, is to add a seperate section to the module image that can be used to provide this information to the kernel. A recent example in this regard was the aio routines, where if you call the system call, the default for the system call not being implemented is to signal (and, by the default behaviour, kill) the process. Only if you trapped the signal did the call return -1 with errno set to ENOSYS. Arguably, it should have loaded the AIO module, and "just worked". NB: The security issues that led to it being a module in the first place are unlikely to be addressed at all, if they are not a threat because they are in a module which is not loaded by default, which is bad. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
