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

[Noah Gibbs]

--- Josh Dady <jpd at indecisive.com> wrote:
> One way to go about this would be to start with
> maintaining abstract 
> meta-data about entries in the filesystem.

  The problem with this, from my point of view, is
tracking.  File permissions in Unix (and DOS, and to a
lesser extent Mac) are pretty much like this.  But the
problem is that there are non-DGD methods of file
manipulation that must still be allowed...  Editing on
the fly from a shell account is a non-optional feature
IMHO.

  That makes an in-memory mapping an unusable tool for
the task.  An on-disk mapping isn't any better because
if DGD can manipulate it at any time, you can't ever
safely edit it.  Not good.

  You could do the permissions in a file
per-directory, but it would have most of the same
problems on a slightly smaller scale.

  Keeping permissions as metadata in the file prevents
abuses from within the MUD since DGD can only supply
the "real" data in response to a read_file().  I
suppose you could treat any outside editing of the
file as an attempt to change permissions, so a file
with invalid permissions would simply be disallowed --
say if you had a file that somebody else owned, with a
big chunk of their permissions, in your directory. 
But then you'd need another permissions method to vet
your existing one...  It becomes a chicken-and-egg
problem.

  I guess you could just make sure that none of the
other admins have shell access, and treat any edit
from the shell as being able to set any possible
permissions on the file.  I *really* dislike that
idea, though.

  So yeah, metadata is a good idea, but where would
you store it?  How would you update it?

> If I was building "from the ground up", I'd
> at least consider building 
> on DGD's native semantics in layers

  Absolutely.  One possibility would be to have a
"build a Kernel" kit so you could select Kernel object
tracking, automatic object tracking or no object
tracking, and then independently select one of three
or four methods of file security.  So you could break
the Kernel up into its component parts and assemble a
custom Kernel.  It'd be neat.

  But that still doesn't solve the problem of how one
or another particular method of file security would
work.  You can build in layers, but you still have to
choose what to build.

> -- one layer would just add 
> properties (which admittedly could still be
> stored in one colossal 
> mapping somewhere) that inherently follow the
> file to which they're 
> attached around.

  This is the real weakness in the system.  Do you
need to add an entry to this mapping every time you
add/edit a file?

  So yes, you can do some really cool stuff with
arbitrary metadata.  But how would you store the
metadata?  I guess you could register defaults
per-directory, which would be kinda like the Kernel
Library (but potentially much less restrictive).  But
then you'd still have to set the mapping value
manually every time you added a file with different
permissions than its directory, which is prone to
nasty security errors, and is a pain all 'round.



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