In article <1991Sep21.170218.5667@bronze.ucs.indiana.edu> kellehe@silver.ucs.ini
ana.edu (Mike Kelleher) writes:
>
>Most silly 3.0 questions, I hope there getting more intelligent as we go
>allong. Does anybody have a suggestions as a whole for secuirty measures in
>3.0? There are several calls like Get_rootid that really bother me.
>anyone got some suggestions?
The name 'root' has nothing to do with the login name 'root' on unix
systems. The only common thing is the spelling.
The 3.0 has a new security system, which is not used if -o is specified !
The new security system has been inspired by the Unix way of handling
user id (uid) and effective user id (euid), but is not exactly the same.
Every object will have a uid and a euid. It is the euid that governs what
permissions the object will have. The euid can be changed.
The game driver only maintains these two values, represented as strings. It
is the master.c that defines what they mean. The values can be any string,
but one good way is to use the name of the wizard.
When an object wants to access a file, valid_read (or valid_write) will
be called in master.c, which will make a decision depending on the path
name of the file and the euid. The 2.4.5 game driver called the valid_read in
player.c, which was quite bad when there were no "current player".
The euid can be changed to only some other values by the object, but always
to the value of the uid. This is also defined by the master.c object.
There is no set-uid as in Unix, but there is a possibility to transfer
your euid to another objects uid. If object A do seteuid(0), then any
object B can do export_uid(A) which will set the uid of A to the euid
of B.
There are some special rules (which I won't list here) which define what
happens when an object makes another object become loaded. These rules are
currently hard-coded in the game driver, but will probably also be transfered
to master.c. In general, a loaded object either gets the same uid as the euid
of the loader, or 0 (means no permission).
This new security system is in many ways compatible with the old system. The
big difference is that when a wizard A makes a room be loaded that was defined
by wizard B, then you don't want that room to have uid A. Instead, it will
have 0, which means that it must set the euid to something to be able to
do any file access. This might seem arduos, but as all new mudlib systems
are defined in a hierarchical way, a single line in a single file will
(should :-) do it.
There are some interesting problems resulting from this. For example, a
player.c object can't call save_object() without preparations because it
doesn't normally have permission to modifiy player save files.
This is solved by talking with the master.c. The player object first sets its
euid to 0, then calls a special request function in master.c which will
give the player object the "root" uid. Now, the object can do the save,
set back to euid 0 and return control to master.c. Of course, the master.c
will validate that it is actually the player object, not something
made by a wizard.
Even if an object has euid "root", it can't access files outside the
mudlib directory. This is never ever supposed to be possible.
The wizlist modifications are now based on the uid of the object. That means
that "root" can show up, as well as "backbone".
Lars Pensj|
lars@cd.chalmers.se
