[MUD-Dev] TECH: programming languages (was: Re: TECH: STL / Heaps, etc.)
justin at mlstoday.com
Sat Aug 18 20:29:17 New Zealand Standard Time 2001
> 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
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
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
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
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
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 at mlstoday.com
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev