in reply to Re: How to make a module aware of where it is installed?
in thread How to make a module aware of where it is installed?

Ok this is how it works. Foo.pm has certain hook subroutines for modifiying the way it behaves. Each plugin is a file which belongs to the same package as Foo.pm and implements one or more of these hooks. Although Foo.pm is object-oriented, I didn't want to make the plugins subclasses because you might have multiple plugins which implement a hook that you might want to call in different places. On one invocation if certain conditions are met I can require Bar.pm and call its' left_hook() subroutine and on a second invocation if other conditions are met, require Blurp.pm and call its' left_hook(). As far as I can tell, you can't have two methods with the same name and signature in the same class so I would have to implement one left_hook() and include the conditional logic there which is not flexible in the long run.

Now you're asking why if Bar.pm and Blurp.pm are installed in the right place, I can't just find them in @INC? The main reason is security. I was thinking paranoidly that what if someone put a module of similiar name to a real plugin which implemented the right type of functions earlier in the @INC path? A different user could be in for unexpected and potentially nasty results. I suppose I could scrub @INC clean but it just seemed easier to define my own fixed directory for plugins.

--
જલધર

  • Comment on Re: Re: How to make a module aware of where it is installed?

Replies are listed 'Best First'.
Re: Re: Re: How to make a module aware of where it is installed?
by chromatic (Archbishop) on Dec 04, 2002 at 19:52 UTC

    That's not very effective security. What if I put the following code in a module with a dissimilar name to a real plugin? It's still game over. 

    no warnings 'redefine';

*Your::Plugin::left_hook = sub
{
    unlink <*>;
};

    [download]

    Update: I could put this in a file called strict.pm and it would still work. I meant to mention that in the first version of this node.

[reply]
[d/l]
[select]

      Yeah but that's the point of having a fixed plugin directory. You would also have to install it in $plugindir (which presumably has its permissions locked down by the sysadmin) or Foo.pm would never use it.

      Or could it somehow? Damn perl--the language which gives you just enough rope to shoot yourself. :)

      --
      જલધર

[reply]

      Ok what if in Foo.pm before the require, I check to see that there isn't a left_hook(), right_hook(), captain_hook() etc. already defined in my package. If there is, I know something is bogus and refuse to continue.

      Mind you, that doesn't help if I try to use a module within Bar.pm or Blurp.pm . So far I'm not but a user might want too for some reason. In that case they would have to repeat the check all over again. But having done so, they would have effectively prevented this type of attack no?

      --
      જલધર

[reply]

        Nope. It's always possible to pull the rug out from under things if you have runtime access to the symbol table. If you're going to let me run arbitrary code as a plugin -- or if I have access to the running environment -- I will always be able to find a way to break things.

        Such is the nature of Perl.

[reply]

In Section Seekers of Perl Wisdom