MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | CONCEPT |
| 2 | uids (userids) |
| 3 | |
| 4 | DESCRIPTION |
| 5 | Every object in the mud is attributed with a user-id 'uid': a string |
| 6 | which associates the object with a certain 'user' (aka 'wizard' or |
| 7 | 'creator', though it is not limited to that). The uid can be 0, which |
| 8 | internally is the default-uid. |
| 9 | |
| 10 | The uid serves a dual purpose: on the on hand it is used to gather |
| 11 | statistics about the various groups of objects (in the famous |
| 12 | 'wizlist'), on the other hand the uid can come in handy in the |
| 13 | implementation of security systems. |
| 14 | |
| 15 | The uid of an object is assigned at its creation through the |
| 16 | driver hooks H_LOAD_UIDS for loaded objects, and H_CLONE_UIDS |
| 17 | for cloned objects, and can't be changed afterwards. |
| 18 | |
| 19 | The uid of an object can be queried with the efun getuid() (resp. |
| 20 | creator() in compat-mode). |
| 21 | |
| 22 | |
| 23 | Every object also has a second string attribute, the 'effective |
| 24 | userid' or 'euid', which also may be 0. This value was intended to |
| 25 | implement a security system based on difference between theoretical |
| 26 | and effective permissions. Since the effectiveness of this system is |
| 27 | doubtful, the driver enforces such a use only as an option. |
| 28 | |
| 29 | As uids, euids are assigned at an objects creation through |
| 30 | the two aformentioned driverhooks. They can be queried with |
| 31 | the efun geteuid() and changed with the efun seteuid(). Calls |
| 32 | to the latter are verified by the master lfun valid_seteuid(). |
| 33 | |
| 34 | Additionally objects can impose their uid onto an other objects |
| 35 | euid with the efun export_uid(). |
| 36 | |
| 37 | |
| 38 | If the driver is run in 'strict euids' mode, euids are taken |
| 39 | more seriously than being just another attribute: |
| 40 | - all objects must have a non-0 uid. |
| 41 | - objects with a 0 euid can't load or clone other objects. |
| 42 | - the backbone uid as returned by master::get_bb_uid() must |
| 43 | not be 0. |
| 44 | |
| 45 | |
| 46 | Userids are assigned at the time of the creation of an object |
| 47 | by calling the driverhooks H_LOAD_UIDS and H_CLONE_UIDS: |
| 48 | |
| 49 | mixed <load_uids closure> (string objectname) |
| 50 | mixed <clone_uids closure>(object blueprint, string objectname) |
| 51 | |
| 52 | When an object is newly loaded, the H_LOAD_UIDS hook is |
| 53 | called with the object name as argument. |
| 54 | When an object is cloned, the H_CLONE_UIDS hook is called |
| 55 | with the blueprint object as first and the clone's designated |
| 56 | name as second argument. |
| 57 | In both cases the new object already exists, but has 0 uids. |
| 58 | |
| 59 | For the result, the following possibilities exist (<num> is |
| 60 | a non-zero number, <no-string> is anything but a string): |
| 61 | |
| 62 | "<uid>" -> uid = "<uid>", euid = "<uid>" |
| 63 | ({ "<uid>", "<euid>" }) -> uid = "<uid>", euid = "<euid>" |
| 64 | ({ "<uid>", <no-string> }) -> uid = "<uid>", euid = 0 |
| 65 | |
| 66 | If strict-euids is not active, the following results are |
| 67 | possible, too: |
| 68 | |
| 69 | <num> -> uid = 'default', euid = 0 |
| 70 | ({ <num>, "<euid>" }) -> uid = 'default', euid = "<euid>" |
| 71 | ({ <num>, <no-string> }) -> uid = 'default', euid = 0 |
| 72 | |
| 73 | |
| 74 | |
| 75 | Slightly different rules apply to the (e)uid of the master. |
| 76 | The masters (e)uid is determined by a call to |
| 77 | master->get_master_uid(): |
| 78 | |
| 79 | "<uid"> -> uid = "<uid>", euid = "<uid>" |
| 80 | |
| 81 | In non-strict-euids mode, more results are possible: |
| 82 | |
| 83 | 0 -> uid = 0, euid = 0 |
| 84 | <num> -> uid = 'default', euid = 0 |
| 85 | |
| 86 | If your uids are in general based on filenames, it is wise to return a |
| 87 | value here which can not be legally generated from any filename. OSB |
| 88 | for example uses 'ze/us'. |
| 89 | |
| 90 | The masters uid is determined only on startup this way, at runtime the |
| 91 | uids of a reloaded master determined as for every object by a call to |
| 92 | the appropriate driver hooks. |
| 93 | |
| 94 | SEE ALSO |
| 95 | native(C), get_root_uid(M), valid_seteuid(M), |
| 96 | objects(C), clone_object(E), geteuid(E), getuid(E), seteuid(E) |