[MUD-Dev] TECH: programming languages (was: Re: TECH: STL / Heaps, etc.)

[Justin Rogers]

[Bruce]

> Care to describe the .NET security model in more detail, or
> pointers to publicly available documentation?  Is it ACL-based?
> I'm assuming that it isn't capability-driven.  How close is it to
> that of Java?  To what extent can you implement your own security
> policies?  Does it have a means for tracking clean vs dirty data
> like Perl does?  What else is interesting about it?

Well, obviously the best location is going to be to install the SDK
and then view the documentation.  We haven't done too many samples
about permission (that I've seen at least) so I'm not sure about
where to point you there (I own the QuickStarts and I can say that
I've programmed 0 samples because we cut them do to time
constraints).

However, Security is extremely powerful.  So I'll work through your
questions and then see if anything additional needs to be added.

  1.  Is it ACL-based?

    No, it is request/demand/refuse based.  First off you have a
    system wide set that you establish using our caspol utility.
    This sets the global security policy.  You get to select which
    permissionsets (Local, Intranet, etc...) have what security
    options.

    You can also establish a policy at the App-Domain level.
    App-Domains are lightweight processes.  You can have multiple
    app-domains running under you application can you can be
    controlling each of them.  Each with different security
    permissions.

    You can specify security attributes on any libraries you
    implement (for instance you could request that the user code
    running under App-Domain A first demand some custom permission
    before accessing your file io function in your library).

  2.  How close is it to Java?

    Kind of close since you have to request permissions.  Can this
    turn into some call which the user sees?  Not sure about that,
    but I think not.  I think you simply get an exception you can
    catch if you perform some security violation.

  3.  Can you implement new permissions?

    Yes.  You override CodeAccessPermission and implement an
    interface.  That being done you now have a custom code
    permission class.  Then you create a new named permission set,
    tell it about your new access permission.  Somewhere in your
    code (your library calls) you should request that this
    permission exist for the call to succeed (in this manner user
    code would have to request permission before it could call your
    library code).

  4.  Clean vs dirty data?

    Unsure about what you're talking about here.  But if it helps
    there is going to be a Perl.NET and I've been told our security
    model adapted well to theirs.

  5.  What else is interesting?

    Simply the fact that you can add your own permission sets, that
    you can set global security policies, place code access security
    declaratively using attributes, imperatively by calling function
    calls, and at the app-domain policy so you can isolate code from
    having the same permissions sets as the called program.  All of
    those features seem pretty interesting.

    Is it extremely performant?  I don't know, haven't run any perf
    tests myself.  Haven't even really used many of the features of
    our security model since the default security works perfectly in
    most cases (yes we do bind the machine security policy to the
    user account).  This is our Role-Based security or principal
    security.

These are my findings having read the various whitepapers and
documentation available to me.  Some of it may be wrong (thank the
UE guys), some of it may be really wrong (gotta get some reading
glasses), but most of its probably right!

Justin Rogers
justin at mlstoday.com


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev