[erlang-questions] Preventing calling some functions

Vasilij Savin vasilij.savin@REDACTED
Sun Dec 13 15:24:39 CET 2009


Greetings,

Let's take a look at example. We have some server/application like Facebook
and allow third-party plugins. Would you allow all and everybody to mess up
with the core functionality that is there? I would really not trust
explicitly other programmers that much, because even unintended mistake
would crash the system probably and also it allows 3rd party authors to take
shortcuts and take shortcuts instead of using suggested APIs.

I do not think it is defensive programming, because it should be some sort
of built-in mechanism that prevents 'unauthorised' calls. Though at this
moment I do not think there is such thing, since the intent during creation
of Erlang was quite different.

Regards,
Vasilij Savin


On Sun, Dec 13, 2009 at 2:40 PM, Jayson Vantuyl <kagato@REDACTED> wrote:

> > Hi,
> >
> > I don't see why I should have more trust and confidence in the creator of
> the server application itself then in the creator of a plugin.
> > If I want to restrict a plugin from doing something particular on my
> machines, I would restrict the server itself in the first place.
> I don't particularly buy this.  I think that there are plenty of reasons to
> lock-down a plug-in that have nothing to do with trusting the author or not.
>  If security is at all a concern, it's perfectly reasonable to attempt to
> achieve a high-level of compartmentalization between components.  The
> principle of least privilege is a good one, even within an application.  The
> plug-in author doesn't have to be malicious for her code to be abused.
>
> > Your second point sounds like "defensive programming". See: http://www.ercore
> team can get stuck maintaining old APIs because third-party
> lang.se/doc/programming_rules.shtml#HDR11<http://www.erlang.se/doc/programming_rules.shtml#HDR11>
> I heartily agree on this point.
>
>
> --
> Jayson Vantuyl
> kagato@REDACTED
>
>
>
>
>
>


More information about the erlang-questions mailing list