Subj : Re: linux permissions issue
To   : Digital Man
From : tenser
Date : Thu Sep 04 2025 10:12:48

On 02 Sep 2025 at 10:27p, Digital Man pondered and said...
 
 DM>   Re: Re: linux permissions issue
 DM>   By: tenser to Digital Man on Tue Sep 02 2025 01:01 am
 DM> 
 DM>  > If I log into a terminal, for example, then I "own" that machine.
 DM> That doesn't sound like a very multi-user freindly OS.

It is, though.  Kinda.  Let me explain....

Plan 9 divided the network into three categories of machines:

1. Terminals, which were the computers you sit in front of and
interact with.  These boot from the network, have middling CPU
and RAM profiles, usually no local disk, but excellent HCI
facilities (graphics, monitor, keyboard/3-button mouse, sound).
They tend to have a middle-of-the-road network interface.

2. CPU servers, which provide bulk compute, or specialized services
for the rest of the network (e.g., authentication service, network
boot services, etc).  These also boot from the network (usually,
except for the CPU server(s) that runs the auth/boot services), have
lots of fast CPUs and RAM, no HCI facilities to speak of (usually
just a serial port) and a very fast connection to the file server.
If there's local storage attached to a CPU server, it's either to
hold e.g. the auth database, or to provide scratch space.  There _is_
usually a small amount of NVRAM holding key data so that the CPU
server can authenticate itself to the file server.

3. File servers, which provide bulk storage.  These are standalone,
have middling CPUs, lots of RAM to cache file data, and have lots of
very fast disks and a very fast network connection(s).  Like CPU
servers, there are no real HCI facilities to speak of; just a serial
port.  These interact with authentication servers to authenticate
incoming connections.  The original file server ran a special kernel
that did nothing by serve files (in kernel mode; administration via
the serial port was provided by a built-in monitor), but it was
replaced by a user-space file service program running on a standard
CPU server a few decades ago.

Usually, users interact with the system by logging into a terminal;
when it boots, it asks for a user login name and a password, and
connects to the authentication server to authenticate the user.  If
successful, the user becomes the host owner of the terminal, and
that's their interface to the rest of the network.  Terminals tend
not to run services, so yeah, they are de-facto single-user machines,
but a user _could_ run something if they wanted that would allow another
user to connect.  But terminals are mostly uninteresting so for all
intents and purposes, no one really does that.

Conventionally in Plan 9, resources are accessed via a file-like
abstraction, and users can mount any resources they have access to into
their local (mutable, per-process) filesystem namespace; `mount` is not
a privileged operation, since it only affects the local process-group.
There is a separate operation called "bind" that lets me assign a new
name to a file (or directory) in my namespace.  Again, namespaces are
process-private, so this is unprivileged: I can affect the namespace of
my process, but no one else's.

All of these "files" are served via a single, universal, file protocol
called "9p".  9p participates in the authentication protocol served by
the auth server mentioned above, and by default uses TLS for privacy.

The impact is that users tend to assemble the set of resources they find
interesting or useful into a session on their terminal; those resources
may be served by machines elsewhere on the network, however.

When a user needs computational power beyond what their terminal provides,
however, they can connect to a CPU server via a command (called `cpu`).
The effect is similar to logging into a remote system using something
like `ssh` or `rlogin` (or maybe `telnet`) in the Unix world, but it
works a bit differently: one brings one's namespace, which is imported
into the environment of the process that's started on the remote server
(running as the local user).  Conceptually, one might think of this less
as "logging into" a remote system, but more like importing CPU and RAM
resources from the remote server.

The means by which a user starts a process on a remote system as themselves
is a bit interesting and deserves some mention.  I said there was no
superuser, and that's true, and only a host owner, which is just an
ordinary user.  And that's true, so how does a user start a program on
a CPU server that's owned by some random user?  The answer is that the
kernel provides a cryptographic _capability_ facility that interacts
with a trusted software agent that authenticates users (against the
authentication server) and grants them access to a capability that they
can present to the kernel that lets them change their user ID to that of
the user they authenticated as.

So yeah.  It _is_ a multiuser system, but there's no root; host owners
are kinda sorta similar on CPU servers, but it's a much weaker concept.

--- Mystic BBS v1.12 A48 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.