9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Factotum vs SASL
Date: Tue,  2 Dec 2014 05:00:39 +0100	[thread overview]
Message-ID: <547D3967.2020200@gr13.net> (raw)
In-Reply-To: <20141201103810.GA541@polynum.com>

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



  parent reply	other threads:[~2014-12-02  4:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17  5:03 Enrico Weigelt, metux IT consult
2014-11-17  5:57 ` Lyndon Nerenberg
2014-11-17  6:29 ` lucio
2014-11-17 13:58   ` erik quanstrom
2014-11-17 14:14     ` lucio
2014-11-18  8:22 ` Skip Tavakkolian
2014-11-29 19:46   ` Enrico Weigelt, metux IT consult
2014-11-29 19:46     ` erik quanstrom
2014-11-29 21:20       ` Enrico Weigelt, metux IT consult
2014-11-29 21:23         ` erik quanstrom
2014-12-01  6:28           ` Enrico Weigelt, metux IT consult
2014-12-01  7:00             ` lucio
2014-12-01 10:38               ` tlaronde
2014-12-01 10:45                 ` lucio
2014-12-02  4:00                 ` Enrico Weigelt, metux IT consult [this message]
2014-12-02  4:08                   ` erik quanstrom
2014-12-02 15:40                     ` plannine
2014-12-02 16:33                       ` Wes Kussmaul
2014-12-02 20:32                       ` Skip Tavakkolian
2014-12-02 22:20                       ` Enrico Weigelt, metux IT consult
2014-12-02  9:50                   ` Richard Miller
2014-12-02 22:15                     ` Enrico Weigelt, metux IT consult
2014-12-01 12:14             ` Stuart Morrow
2014-12-02 20:32     ` Skip Tavakkolian
2015-01-01 14:55     ` Teodoro Santoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547D3967.2020200@gr13.net \
    --to=enrico.weigelt@gr13.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).