[DGD] Persistent library design, initialization and data integrity

[Noah Gibbs]

  In addition to creating objects from UNQ, you can generate them on demand
with the @new_room script and its relatives.  So UNQ is only one way to
initially produce objects.

  Yes, you could potentially make objects start out belonging to an admin and
later transfer them to the ownership of the MUD proper.  You'll need to be
careful with who creates them, though.  The Kernel primarily tracks object
ownership by who the initial creator is, which is one reason the MapD owns
everything in Phantasmal :-)

  Securing the system in Phantasmal is easy enough -- you know what user is
asking to copy or change information in a room.  So decide if they have the
privilege to do it.  The reason it's not more secure currently is that I don't
have a good privilege scheme worked out for full admins versus various flavors
of sub-admins.

  It's not easy to transfer ownership of objects in the Kernel library, but
since Phantasmal makes sure that you can write an object out to UNQ and
reconstruct it, this method could be used to make a new object owned by the
system proper.  Or you could just leave everything under MapD's ownership but
marking areas (zones) by who is allowed to modify them, and then you wouldn't
need to transfer object ownership in the Kernel's eyes.  Just move rooms from
an experimental zone where the admin can write but players can't enter, to a
production zone where sub-admins can't change it and the players can enter.

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

> 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
> 
> 
> 
> 
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com