Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #87138 > unrolled thread

Re: Question about importlib

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about importlib "Frank Millman" <frank@chagford.com> - 2015-03-08 09:53 +0200

#87138 — Re: Question about importlib

"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmrXp4MSO9f=xb_BRuPnRZ7XRKsKTkbFvo-e5N7Lr_MVVg@mail.gmail.com...
> On Sun, Mar 8, 2015 at 6:30 PM, Frank Millman <frank@chagford.com> wrote:
>> Actually, as I write this, I realise that there is a more important 
>> question
>> that had not occurred to me before. Is this a potential security risk? My
>> intention is that the caller would only call functions within my own
>> modules, but this could be used to call any arbitrary function.
>
> Here's an easy solution to both halves of your problem. It guarantees
> that arbitrary functions can't be called (or at least, that functions
> from arbitrary modules can't be called), and guarantees predictable
> performance:
>
> modules = {
>    "some_module": some_module,
>    "another_module": another_module,
> }
>
> module_name, func_name = func_name.rsplit('.', 1)
> module = modules.get(module_name)
> if module: getattr(module, func_name)(caller, xml_elem)
> else: cope with invalid choice of module
>
> You could programmatically populate the dictionary (eg from a list of
> acceptable module names) either with importlib or by pulling them from
> sys.modules. But whichever way you do it, you have an easy guarantee
> that arbitrary modules won't be imported, guaranteeing both security
> and performance in one stroke.

That is a neat solution. Thanks, Chris

Frank

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web