In article ,
Iain Hibbert 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
>>
Am 05.08.11 09:27, schrieb Iain Hibbert:
> 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
On Nov 20, 8:34pm, Iain Hibbert 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 modu
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 charac
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 still works, but must be availab
Am 04.08.11 13:37, schrieb John Nemeth:
> On Dec 25, 7:20am, Marc Balmer wrote:
> } 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/pla
On Dec 25, 7:20am, Marc Balmer wrote:
} 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
}
} T
Am 04.08.11 12:49, schrieb Edgar Fuß:
>> 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,
> it must start with either '.' or '/'
Do you rather mean ``./'' or ``/''? Do you want to allow .module,
.modules/module or ../module?
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_
Am 03.08.11 09:23, schrieb Alan Barrett:
> 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
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 construc
i like the current method. it is how pretty much all other
systems i'm familiar with work, too.
.mrg.
modload looks for modules first in the current working directory, if not
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
14 matches
Mail list logo
