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

[Noah Gibbs]

--- 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.

>  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 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".

  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?



=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd