[erlang-questions] Scoped group leaders

[Eric Merritt]

> On Mon, Jul 4, 2011 at 10:15 AM, Ulf Wiger <ulf.wiger@REDACTED> wrote:
>
> On 4 Jul 2011, at 16:15, Eric Merritt wrote:
>
>> I can actually see a ton of uses for this. Not the least of which is
>> security, I just did a deep security piece in an erlang app, and it
>> turned out well, but I could see where something like this would have
>> made it much more elegant
>
> How, exactly?

In the existing model a context is passed through out the system,
identifying the users and their capabilities. In this case, assuming
that all threads related to use where spawned at some level by the
incoming process, a context would not have had to be passed, it could
have been implicit in the group leader. This would have been much less
invasive in the system. I made no attempt to protect against
developers adding malicious code to the system. That is hard
regardless of the model. Perhaps this would have been better called an
access control system rather then a security system given the
assumptions.

>
> The things that are difficult to do today, in terms of security in Erlang, is to *enforce* security in a way that cannot be subverted.
>
> Group leaders are natural for IO, since IO necessarily involves sending a message to some entity. Some other things are overloaded -
>e.g. the application controller using the group leader to find out which application a process belongs to. That is a clear case where I think
>this would be useful: an "application group leader". But for security, I don't see it solving any of the problems I consider difficult - perhaps
>this is my failing: after having implemented reasonably transparent security in ErlHive, I get all kinds of associations to nasty problems
>that wouldn't be helped by this suggestion. But perhaps you are viewing it from a different angle?
>

I am not thinking about this as solving any truly hard problems, not
that can't be solved in some other way. It just would have made the
code created for this project, more elegant, and the security aspects
much less invasive then they currently are, at the cost of slightly
more difficult testing and some knowledge about where the process
group boundries are.


>
> BR,
> Ulf W
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
>