[DGD] Alternatives to the Kernel model of security...

[Greg Lewis]

On Wed, Jan 28, 2004 at 10:02:19AM -0800, Noah Gibbs wrote:
> --- Greg Lewis <glewis at eyesbeyond.com> wrote:
> > A lot of the focus in this thread seems to be
> > on files and filesystems.
> 
>   Well, yes.  I was probably going to start another
> thread after this on other parts of the Kernel
> Library, if any other ones seemed nicely separable. 
> File security was an easy part to discuss by itself. 
> It's not like we don't talk about its restrictions on
> inheritance often enough already :-)
> 
> > I'm wondering if this fundamental
> > assumption isn't flawed.
> 
>   You make a good and interesting point here, but
> you're missing something vital.  People have already
> written a wide variety of tools that we don't want to
> keep them from using.  Existing file editors are a
> quantum leap above anything one of us could reasonably
> dummy up in LPC in a year or two.  Dismissing them out
> of hand is a bad idea, because our users would really
> like to use them, and we'd really like not to maintain
> them.
> 
>   So we could say "okay, no files."  But then we're
> still going to have to address the issue of easy file
> importation in one way or another, because everything
> that _surrounds_ DGD uses files, including the code of
> the server itself, and probably the MUDLib as well.

Maybe I didn't read your original question correctly, but
I'm not suggesting "no files" at all.  I've worked on enough
LPMud's to know that ease of editing is important :).
This isn't necessarily a problem that hasn't been faced by
the alternatives I suggested looking at too.  Cold, for
example, uses objects written in the ColdC language, so
clearly ease of editing is also something which has come
up there as well.  I believe Cold also (optionally) has
the ability to read/write files on the native filesystem
(the ColdC code itself is stored in the database).

> >  With DGD's persistent nature, you
> > could easily run into a situation where you
> > decide to completely rearrange
> > the filesystem layout but want to keep existing
> > objects.
> 
>   Absolutely.
> 
> >  In this case, a permissions system based on
> > filenames is going to
> > be a hindrance more than anything else as you'll
> > have to make
> > some compromises to preserve the original object
> > permissions.
> 
>   Mostly, yeah.  You can see this very thing in the
> Kernel Library when you're doing serious
> reorganization of a MUD based on it.  I speak from
> experience :-)  You're right, having the permissions
> encoded in the filename is kind of a hack, though it
> makes certain problems much easier to solve.  Your
> suggested alternative has flaws, though...

I haven't suggested an alternative other than "see how
they do it in Cold Core, for example, and whether any
of its ideas are worth trying" :).

> > I haven't looked into this myself, but it may
> > be helpful to
> > look at the permission systems used in "cores"
> > for drivers
> > like Cold or MOO [...]  [S]ince the
> > only storage mechanism is persistent (a database),
> 
>   Yeah, that means they can get around this by not
> allowing more or less random access...  A database is
> harder to use a file editor on, and you can more
> reasonably say "and if you do, we take no
> responsibility for your data integrity".

Actually, the database is a binary format, you can't just
edit it with a file editor (well, you can, but doing so is
a pointless exercise).  You can make a text dump of the
database containing the ColdC code, but I doubt thats
there solution for ease of editing files...

>   DGD could do that, but there go all those file
> editors, and essentially any shell/GUI tool that
> changes files.
> 
>   WebDAV, which others have recommended, has the
> advantage of allowing a similar interface, and the
> disadvantages of being hard to use, not very portable
> and being completely unfamiliar to most potential
> users.  NFS has the same problems, but appeals to a
> different subset of users (i.e. Linux rather than Mac
> or Windows).
> 
> > the
> > permission systems won't be file based at all.
> 
>   Okay, say you do it per-object rather than per-file.
>  How is that different from just disallowing shell/GUI
> editing of all your source files and keeping a
> mapping?  You've still 'solved' the problem by saying
> 'no non-DGD tools can touch the source files', which
> is fine as long as you think that an editor you
> cobbled together yourself and cut-and-paste are the
> state of the art in editing.
> 
>   Yes, you can use vi or emacs over FTP (maybe --
> don't you have to install Ange-FTP into emacs to do
> this?), but that's still making things hard for your
> builders/admins.  Short of writing a custom client for
> your admins, it seems essentially impossible to get
> these things to work together.
> 
>   Anybody see a way to circumvent the problem without
> disallowing non-DGD access to all the DGD files?

Note, I didn't suggest disallowing non-DGD access to files at all,
although access from outside the MUD can possibly circumvent all
file location based permissions.  I'm merely suggesting that the
permission system not have the location of the file which originally
contained the code for the object be the basis for the permission
system.  I'm interested in what others have done in this area and
wonder how well it would apply to DGD.   As Felix mentioned, some
alternatives have already been explored in the LPMud space.  Maybe
others are using these flawed approaches, or maybe they're using
a different approach which may map well into DGD space.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd