From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <547D3967.2020200@gr13.net>
Date: Tue,  2 Dec 2014 05:00:39 +0100
From: "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <547C0A85.9090906@gr13.net>	<873a3482d7cbc73496b64baa73c718a5@proxima.alt.za>
	<20141201103810.GA541@polynum.com>
In-Reply-To: <20141201103810.GA541@polynum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Factotum vs SASL
Topicbox-Message-UUID: 318f0dd2-ead9-11e9-9d60-3106f5b1d025

On 01.12.2014 11:38, tlaronde@polynum.com wrote:

Hi,

> But, IMHO, this is precisely the difference between Unix and Plan9.
>
> In Unix, the console or X11 are dumb terminals. There are only
> no-computing-capabilities devices to interact; they are no terminals as
> in Plan9.

Okay, than that's perhaps what I'm missing yet.

To mimic the usual Unix behaviour, I would need some getty/login-alike
program, which asks for login credentials and then starts up things
like shell or gui (some window-manager-/DE-alike program) as the
corresponding, which then is _not_ the hostowner.

If I understood it correctly, hostowner factotum can authenticate
other users and startup proceses under their UID, right ?

So, in my scenario, hostowner would act as kind-of-root, just being
responsible to bring up certain fundamental servers, start the login
program, which in turn asks for credentials, and starts this user's
shell with certain filesystems (services) mounted in. A bit similar
to an local xcpu or ssh connection, just with local console services
(/dev/cons, /dev/draw, etc) mounted (bot not all the raw kernel devices)

> This is why X11 has put the network in the wrong place. The X11 "server"
> is just a remote graphic card; it is mimicking with graphical devices
> what has been done with text devices (tty). In X11, all processing,
> including handling the graphical menus, the display, is done by
> the client.

Well, it's like an (pretty complex) devdraw with multiple windows,
isn't it ?


To get back to my original intention:

I'm looking for proper ways for access control of certain privileged
operations on GNU/Linux / Unix machines where users (even the guy on
front of the keyboard) are usually unprivileged. I'd like to replace
the ugly dbus/polkit stuff by something plan9'ish.

After thinking through this for a while, my idea is adding some kind
of temporary users/keys to the (hostowner) factotum, which allows an
session controller (eg. the login program) to dynamically give some
session permissons for certain privileged services.

It could go like this:

* on login a new key is generated, which is handed over to the user
  session (maybe via env ?). symetric key should be sufficient here.
* for the services which that user/session shall have access to, this
  key is added in the corresponding factotum instances (eg. hostowner
  factotum for machine control stuff, but maybe also other instances
  for services running under different users, eg. mail servers, etc)
* this user can now connect to these services, and the factotum
  instances already know the proper keys, so authentication runs
  smoothly.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287