1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/wiki/Users Thu Dec 01 17:55:12 2022 +0100
1.3 @@ -0,0 +1,72 @@
1.4 += Users =
1.5 +
1.6 +Since filesystems such as ext2 employ the concepts of users and groups, and
1.7 +since access to such filesystems might be expected to respect the recorded
1.8 +user and group metadata, permitting or denying access to objects as
1.9 +appropriate, the need arises to define a user identity to control access to a
1.10 +filesystem server and the filesystem objects it exposes.
1.11 +
1.12 +== Opener Configuration ==
1.13 +
1.14 +Consequently, a filesystem server may not provide direct access to a
1.15 +filesystem. Instead, it may only expose the [[Components#Filesystems|
1.16 +`Filesystem`]] interface which provides the `open_for_user` operation. This
1.17 +operation is used to configure an [[Components#Openers|`Opener`]] that
1.18 +provides the actual interface for filesystem access as performed by a
1.19 +particular user.
1.20 +
1.21 +Since the `open_for_user` operation involves the indication of an arbitrary
1.22 +user identity, a server providing the `Filesystem` interface should only be
1.23 +exposed to appropriately privileged components. An `Opener` obtained from the
1.24 +operation can then be presented to a less privileged component.
1.25 +
1.26 +== User Structure ==
1.27 +
1.28 +Ordinarily, user information is exchanged using a `user_t` structure defined
1.29 +in [[Libraries#libsystypes|`libsystypes`]] with the following members:
1.30 +
1.31 +|| '''Member''' || '''Description''' ||
1.32 +|| `uid` || User identifier ||
1.33 +|| `gid` || Group identifier ||
1.34 +|| `umask` || File mode creation mask ||
1.35 +
1.36 +The information broadly follows that of a traditional Unix system. Other
1.37 +information, such as supplementary groups might conceivably be provided to the
1.38 +filesystem server separately. Indeed, the user structure might be simplified,
1.39 +removing the primary group information and providing this separately, too.
1.40 +
1.41 +== Opener Configuration in Ned ==
1.42 +
1.43 +The following example illustrates the configuration of an opener and the
1.44 +provision of the opener to a new task in the Lua-based scripting environment
1.45 +of the Ned component in L4Re:
1.46 +
1.47 +{{{
1.48 +-- Obtain user filesystems with umask 0022 (18).
1.49 +
1.50 +local open_for_user = 6;
1.51 +local ext2svr_paulb = L4.cast(L4.Proto.Factory, ext2svr):create(open_for_user, 1000, 1000, 18);
1.52 +
1.53 +l:startv({
1.54 + caps = {
1.55 + server = ext2svr_paulb,
1.56 + },
1.57 + log = { "client", "g" },
1.58 + },
1.59 + -- program, file to create
1.60 + "rom/dstest_file_client", "home/paulb/new file");
1.61 +}}}
1.62 +
1.63 +Here, `ext2svr_paulb` is an opener configured for the user `paulb` who has
1.64 +user and group identifiers of 1000. Since the Lua environment emphasises the
1.65 +L4Re factory mechanism, and since factory operations involve the use of L4Re
1.66 +variable-sized arguments ("vargs") as parameters, the signature of the factory
1.67 +version of the operation consists of the individual elements of the user
1.68 +abstraction:
1.69 +
1.70 +{{{
1.71 +open_for_user(in ipc_varg_sys_uid_t uid,
1.72 + in ipc_varg_sys_gid_t gid,
1.73 + in ipc_varg_sys_mode_t umask,
1.74 + out cap opener)
1.75 +}}}