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

[Josh Dady]

On Jan 28, 2004, at 6:04 AM, Noah Gibbs wrote:

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

This problem is hardly unique to my solution, or even the original 
problem, for that matter. Our FTP service, for example, needs to use 
the MUD's user files, password hashes, and access the 
file-permissions-store.  While only the last of the three actually 
talks to the MUD itself, this communication is still needed.

> Editing on the fly from a shell account is a non-optional feature IMHO.

If your requirements include editing from the shell account with the 
only difference being that the MUD's "/" isn't the shell's "/", then 
your only real options are to write a DGD extension to make use of the 
filesystem's meta-data (I'm including file permissions here) or to 
build a DGD WebDAV server and use an OS that can mount a WebDAV URL as 
a regular disk.

My preferences are to only "edit live" like that on the game server 
when some kind of emergency happens, so I would have different options. 
Methods (off the top of my head) for associating meta-data with files 
include:

   - Store in-file, as discussed (either the permissions themselves, or 
a unique ID)
   - One Big Mapping[tm]
   - One small mapping (_foo.c, .foo.c, etc.) per-file
   - One per directory
   - Encoding a tag into the file-name (foo.c#DECAFBAD)
   - Encoding the properties themselves into the file-name

[long discussion of problems with editing from the shell]

 From my perspective (as one of the game's administrators), a monstrous 
proportion of my creators are using either a semi-modern version of 
Windows, or a modern version of MacOSX, and either of these quite 
happily speaks WebDAV (although the former requires corrective measures 
in my Apache authentication module, due to username pollution), so you 
can see which way I am leaning. The issue becomes whether it would be 
easier to write a provider for Apache's DAV mechanics that chats with 
the MUD or to just build an LPC WebDAV server and hope that if DGD 
doesn't have enough kick to make that workable, that DGD/MP will. 8)

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

First of all, I'm not saying I endorse the One Big Mapping[tm] model, 
only that it could still be used, compared with the existing 
permissions system that I inherited. That detail aside, I think the 
strength (not the weakness) of the layered approach is that if you 
choose to solve the abstract meta-data problem completely and correctly 
first, then adding the permissions layer on top of it is quite a bit 
more straight-forward.

--
Joshua P. Dady
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3322 bytes
Desc: not available
URL: <https://mail.dworkin.nl/pipermail/dgd/attachments/20040128/bfd3b1f6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 174 bytes
Desc: not available
URL: <https://mail.dworkin.nl/pipermail/dgd/attachments/20040128/bfd3b1f6/attachment.sig>