Re: modload_03.diff, was: Don't load kernel modules from the current directory

[christos%astron.com@localhost (Christos Zoulas)]

In article <alpine.NEB.2.00.1108050808300.20467%galant.ukfsn.org@localhost>,
Iain Hibbert  <plunky%rya-online.net@localhost> wrote:
>On Fri, 5 Aug 2011, Marc Balmer wrote:
>
>> This is the third iteration of the patch to make kernel module loading
>> more secure.  The only change to the previous patch is that the code,
>> when loading a module from /stand/... now checks that the module name
>> does not contain a path separator character.
>>
>> modload <name> still works, but <name> must be available in the system
>> module area under /stand/...
>>
>> To load from any other location, either an absolute path or a relative
>> path starting with a '.' is needed.
>
>strchr() is available in kernel I think
>
>also, is this complication of '.' really needed?  What I mean is, if you
>are checking for the path separator, why limit to current directory?
>
>       if (strchr(name, '/') == NULL)
>               path = <module_base>/<name>/<name>.kmod
>       else
>               path = <name>
>
>which is the same semantics used by many other 'automatic file path'
>operations, requiring explicit current-dir to avoid accidents..
>
>(as noted, you didn't exclude ./sub/dir/module anyway)

I agree; all programs that do path searches (shells for example) behave this
way.

christos