[DGD] kotaka

[Shentino]

Kotaka's security system is somewhat straightforward but somewhat
rigid.  The biggest thing is that kotaka is based on the kernel
library.

Kotaka is divided into subsystems, which are treated as users for the
most part, except that a "user" with a capitalized name is treated as
system code and is granted elevated privileges in some cases.

The special KADMIN check will allow anyone using the code command as
the kernel library's admin user, just in case some piece of code wants
to stay secured but allow a backdoor for the admin to fix things.

Many things that the kernel lib reserves for ~System, ~System in turn
delegates to the subsystem/user in question, and often ~Whatever/initd
is consulted for permission or configuration information.

On Thu, Apr 26, 2012 at 2:22 PM, Shentino <shentino at gmail.com> wrote:
> As long as you remember that I'm not gurba's maintainer all is well.
>
> I maintain the kernel library, phantasmal, kotaka, and I do QA on dgd.
>
> gurbalib is bart/aidil's territory
>
> On Thu, Apr 26, 2012 at 2:13 PM, Kent  Mein <mein at cs.umn.edu> wrote:
>> In reply to Shentino (shentino at gmail.com):
>>
>>> > Now I can tell you what I hate about gurba though. ;)
>>>
>>> By all means, spill the beans.
>>>
>>
>> You asked for it....  Before you read further I just wanted to say:
>> I wanted to point out that I'm using it and I'm really thankful for
>> the code and sure maybe it needs some love but its a great base,
>> it just needs some work.
>>
>> Most of what I have is in gurbalib/lib/TODO
>> (https://github.com/sirdude/gurbalib/blob/master/lib/TODO)
>>
>> There seem to be lots of dirs for security that as far as I can tell
>> aren't really used...
>> example: /daemons, /kernel/daemons, /sys/daemons
>> There are 3 levels of users (users,wiz, admin) and wiz and users
>> can't touch any of those so why 3 different locations?
>>
>> The security system also is a bit confusing because you have
>> /std which is inheritables
>> and then:
>> /obj (which I moved to /domains/required to try and cut down on this a bit)
>> and lots of stuff in /obj just inherited the base and that was it...
>> example: /std/corpse.c  /domains/required/objects/corpse.c
>> (going to fix that now... :))
>>
>> There were example cmds for a specific race, and that race did not exist.
>> (Lots of inconsistencies like this most have been fixed I think)
>>
>> add_object_command("shake");    // assumes do_shake, working on making it                                       // like the other one
>> add_room_command("shake","do_shake");
>> (I'm also working on this right now)
>>
>> To tell_room you have to do this sometimes:
>> this_object()->query_environment()->tell_room(who, mesg);
>> // seems elegant but in practice a pain in the hind end...
>>
>> To set the short for rooms you use:
>>   set_brief("Weller Avenue");  // I think set_short would be better
>>                                // but it hasn't bugged me enough to fix it.
>> For an object though you use:
>>   set_in_room_desc("A rock is lying on the ground.");
>> // Its using id's and adjectives but seems like execution is clunky and
>> // hard for new users(me at this point) to figure out whats going on...
>>
>> There are all of these modules in std/body and std/modules, it makes
>> it nice to find specific code to work on in some cases, however it
>> seems like a lot of inheritance and kind of wasteful and sometimes the code
>> isn't where you would guess it is.
>>
>> There is other stuff but hey I think most people are sick of reading by now...
>>
>> Kent
>> --
>> mein at cs.umn.edu
>> http://www.cs.umn.edu/~mein
>> ___________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd