Re: Don't load kernel modules from the current directory
Marc Balmer
> On Wed, 03 Aug 2011, Marc Balmer wrote:
>> modload looks for modules first in the current working directory, if
>> not found there the system module area is searched (/stand/...).
>> [...]
>>
>> The proposed and attached patch changes this in two ways: The module
>> loader never looks in '.' by always constructing a path pointing to
>> the system module area and the function kobj_load_vfs() ensures the
>> path starts with a '/', thus it will only work with absolute paths.
>
> I agree with making the kernel not search "." by default, but it would
> be nice if modload(8) had a way for users to explictly request modules
> from a non-default location.
>
> Perhaps change modload(8)'s "module" argument to be either a module name
> or a file name, using the presence of "/" to distinguish the two cases.
> Then users could pass "./testing.kmod" to load a module from the current
> directory.
The test in the loader can quite easily be changed to test for '/' or
'.' as the first character, and if so load the module from there,
otherwise only look in the system module area.
I will keep that in mind, but first I wait for more feedback.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Marc Balmer
found there the system module area is searched (/stand/...).
otoh, we don't look in '.' when we load libraries in userspace programs,
we even removed '.' from the Lua loader but when it comes to kernel code
we happily accept anything that sits there "by accident".
The proposed and attached patch changes this in two ways: The module
loader never looks in '.' by always constructing a path pointing to the
system module area and the function kobj_load_vfs() ensures the path
starts with a '/', thus it will only work with absolute paths.
The consequence is that kernel modules can only be loaded via the module
loader interface from /stand/<arch>/<name>/<name>.kmod and that
generally only objects with absolute paths can be loaded using
kobj_load_vfs().
Comments?
Alan Barrett
> directory, if not found there the system module area is searched
> (/stand/...).
>
> The proposed and attached patch changes this in two ways:
> The module loader never looks in '.' by always constructing
> a path pointing to the system module area and the function
> kobj_load_vfs() ensures the path starts with a '/', thus it will
> only work with absolute paths.
I agree with making the kernel not search "." by default, but
it would be nice if modload(8) had a way for users to explictly
request modules from a non-default location.
Perhaps change modload(8)'s "module" argument to be either
a module name or a file name, using the presence of "/" to
distinguish the two cases. Then users could pass "./testing.kmod"
to load a module from the current directory.
--apb (Alan Barrett)
matthew green
i like the current method. it is how pretty much all other
systems i'm familiar with work, too.
.mrg.
Marc Balmer
better, it allows to load a module from the filesystem with either an
absolute path starting with '/' or a relative path starting with '.'.
So you can still load a module from the CWD using
modload ./mymodule.kmod
module_load_vfs() is changed in two ways: When a module is loaded from
the path given to modload, it must start with either '.' or '/'. If a
path is constructed to load the module from the system module area, it
must not start with '.' or '/'.
kobj_load_vfs() will only load an object with a path starting with
either '/' or '.'
Comments?
Edgar Fuß
Marc Balmer
>> it must start with either '.' or '/'
> Do you rather mean ``./'' or ``/''? Do you want to allow .module, .modules/module or ../module?
.module would indeed work from the CWD, but then it can not be used to
"poison" and module in the system module area, since those must not
start with a '.'.
John Nemeth
} Subject: Re: Don't load kernel modules from the current directory, second
} This is a multi-part message in MIME format.
} --------------030702090605080608070109
} Content-Type: text/plain; charset=ISO-8859-15
} Content-Transfer-Encoding: 7bit
}
} Thanks to all that replied to my initial diff. This second version is
} better, it allows to load a module from the filesystem with either an
} absolute path starting with '/' or a relative path starting with '.'.
} So you can still load a module from the CWD using
}
} modload ./mymodule.kmod
}
} module_load_vfs() is changed in two ways: When a module is loaded from
} the path given to modload, it must start with either '.' or '/'. If a
} path is constructed to load the module from the system module area, it
} must not start with '.' or '/'.
If you really want to beef up the security of loading from the
system module area, you should make sure there is no / anywhere in
name. Granted, with name being added to path twice, it will be very
difficult to come up with something that will escape the system module
area and load some random module (even without your change to that
part).
} kobj_load_vfs() will only load an object with a path starting with
} either '/' or '.'
}
}-- End of excerpt from Marc Balmer
Marc Balmer
Well, indeed I think the second part of the change to module_load_vfs()
can be ommitted. Primary goal if my patch is to prevent inadvertently
loading from CWD when actually loading from the system module area was
intended.