[DGD] Sensible telnet access for coders

Greg Lewis glewis at eyesbeyond.com
Thu Jan 24 08:18:45 CET 2002


On Thu, Jan 24, 2002 at 05:48:01AM +0100, Arnau Rosselló Castelló wrote:
> I've been trying to find a way to give coders telnet and ftp access to the 
> server, so they can use better text editors than the crude ed in dgd, and i 
> want also that they can keep their source hidden from other coders, and i can't 
> find a way to do it without problems. So far i thought of this:

Don't give them telnet access just for editing purposes.  There are a
number of editors which will edit a remote file to which the user has
ftp access (vim and emacs come to mind).  This simplifies your problem
into simply providing ftp access.

> - Give them a home dir inside the dgd tree, and hardcode in the mud that they 
> only can see and exec the files inside that dir, and perhaps a predefined 
> include and lib dir.
> There would be problems because the file permissions of UNIX won't work, and 
> would be substituted by something probably inferior, that wouldn't let them 
> share the files(perhaps they could trough a "open for all" dir), or give access 
> to some api without admin intervention. 
> The permission system inside the MUD could be refined, but it would be 
> duplicating existing functionality in the OS, besides, often UNIX permissions 
> and MUD permissions would be out of sync, leading to further problems.
> 
> I really can't think of a better way to do it, without dgd supporting some way 
> to find file permissions.
> Well, i know Dworkin is against giving ways to call system() from inside the 
> dgd driver, but maybe creating a limited way to call these functions, like 
> making a line in the config file like:
> system1="chown $arg1$ bla,bla..."
> and a kfun that would call this with the given arguments(maybe with some 
> checks), would add a lot of flexibility to dgd, while shooting yourself in the 
> foot would not be the default, like in the vanilla kfuns.

There are a number of options here, some of them more satisfactory than
others.

1. Write an ftpd in LPC.  This has been done, and you should be able to
   find one and port it to DGD and whatever lib you are using.  It can
   use either the networking kfuns or the binary port.  Obviously you
   tie it into the mud's permission system, which is nice.  Downside is
   you need good LPC skills and a knowledge of the FTP protocol, or at 
   least a working subset of it.

2. Run a standard ftpd, preferably chroot'ed into the mud's main
   directory.  Hack the ftpd to use the mud's permissions by reading
   whatever format permissions are stored in.  This has been done
   before but presents some problems in terms of keeping the permissions
   logic in sync.

3. Run a standard ftpd, give all the coders an account without a useable
   shell with their home directories set to their home directory within
   the mud.  Preferably find an ftpd that will allow a configuration
   which limits users to their home directory or something similar.
   This should also be run chroot'ed.  The obvious drawback here is that
   the coders don't have the same access they do on the mud, although
   they can copy files around inside the mud, which works around most
   of these problems.

Those are some ideas anyway :).  If you're going to use a standard ftpd,
then please run it chroot'ed or run both it and the mud in something like
a FreeBSD jail(8).

-- 
Greg Lewis                            Email : glewis at eyesbeyond.com
Eyes Beyond                           Phone : (801) 796 6999
Information Technology                Web   : http://www.eyesbeyond.com

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



More information about the DGD mailing list