In article <alpine.neb.2.00.1108050808300.20...@galant.ukfsn.org>, Iain Hibbert <plu...@rya-online.net> 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
