[DGD] Persistent library design, initialization and data integrity

[Carter Cheng]

My understanding of MapD after reading over the code is it mainly accepts UNQ files and uses these as input in order to generate objects. This scheme is one of the rather interesting aspects of the Phantasmal library and permeates much of the existing library. So in order to generate new objects under the Phantasmal scheme I assume I would always need to have a relevant UNQ file from which to generate objects from.

So in this case the UNQ file takes the place of the script and provides a secondary location in which data about an extant object is stored. I guess the question I had concerning persistent library design is whether it is safe to discard the "script" as well and whether it is possible to secure the system provided by Phantasmal/Klib in this case (excuse my ignorance). 

One thing I thought that might be interesting to do would be to be able to dynamically configure objects such as rooms then post them to the system (change ownership) once they are mature enough for common use. In a typical LPmud this would involve writing a "initialization script" and the copying it over to the relevant directory and recreating said object using the script. But I am curious if a more direct approach is possible (i.e. constructing and xferring the object directly). Or are there some dire implications to something like this?

Sincerely,

Carter Cheng.



----- Original Message ----
From: Noah Gibbs <noah_gibbs at yahoo.com>
To: All about Dworkin's Game Driver <dgd at dworkin.nl>
Sent: Tuesday, October 16, 2007 9:38:29 PM
Subject: Re: [DGD] Persistent library design, initialization and data integrity


  You're correct that Phantasmal uses a lot more verification code in a
 lot of
places to keep unauthorized callers out.  It's not perfect (the kernel
 lib is
astoundingly correct and consistent on security), but it's not bad.

  Phantasmal doesn't have particularly fine-grained security, partly
 because I
just didn't get to it.  The MapD carefully owns everything, so the
 place to
secure would be the MapD's API.  In a persistent system, and most
 heavily
attacked systems, the approach is similar -- have system components as
 "armed
camps" verifying each request as they come in, and whether the person
 making
the request is authorized to do it.

--- Carter Cheng <carter_cheng at yahoo.com> wrote:

> One of the most salient features of DGD is persistence. As noted on a
> previous thread on the mailing list in theory this means that most
> initialization code can be for the most part done away with since
 many
> objects need to be only initialized once. In my experience from
 working
> primarily with MudOS 90% or more of the code is designed to support
> initialization or initialization code of some sort. 
> 
> I am curious what happens when you start avoiding the initialization
 script
> approach to initializing things on persistent muds. Do you have to be
 more
> concerned about data integrity since the data might be the only place
 where
> that information is kept (there is no redundancy of an init script or
 a save
> file). So instead of spending security effort protecting files you
 (following
> this line of reasoning) have to protect data just as much. 
> 
> This seems like to me it might have two implications- either security
 has
> finer granularity (is this possible under either Klib or Phantasmal?)
 and you
> can fine tune the system to make sure certain calls are restricted to
 certain
> classes of users depending on the object. Or you would have to add
 extra code
> to each set type call in turn to make sure that it isnt called by
 someone
> lacking proper permissions.
> 
> Is this true and are there other implications also when designing
 persistent
> mudlibs?
> 
> 
> 
> 
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 





       
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
 FareChase.
http://farechase.yahoo.com/
___________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd