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: 9fans@9fans.net
Subject: Re: [9fans] Factotum vs SASL
Date: Sat, 29 Nov 2014 20:46:08 +0100	[thread overview]
Message-ID: <547A2280.4020407@gr13.net> (raw)
In-Reply-To: <CAJSxfmJhoSmzOYVP=w7bN9nf7CJ2u+hMUMZdkNVfYON3VUKU-w@mail.gmail.com>

On 18.11.2014 09:22, Skip Tavakkolian wrote:

<snip>

thanks folks ... seems I need to think through all of this more deeply.

If I'm not completely mistaken, factotum can also handle various
authentication protocols, and may be the only one who really knows
the actual secrets.

One scenario I'm thinking about is replacing the password-stores in
certain browsers by an factotum (maybe it could also be useful for
cert handling ?)

A really cool feature, IMHO, would be able to connect my local factotum
to remote ones easily, so I'll get a similar feature like eg. lastpass
is doing for the web. For example, somebody like to give me access to
some remote application, but for some reason can't add my pubkey there
(eg. it doesn't even support such things), but doesn't want to give me
cleartext passwords, he could set things up in his (publically
accessible) factotum instance, which then handles all the auth stuff
for that application.

By the way, that leads me to another topic, which is annoying me
for quite some time: policykit.

For those, who have been spared of it:

It's an invention of the freedesktop folks (or should I call them
"Lennartists" ? ;-o), some kind of proxy, which routes certain dbus
calls (based on certain policies) between several users (and root).
This way, eg. unprivileged users can still be given access to system
level stuff, like network-manager. And that's exactly the point which
regularily hit me (eg. some day my primary account suddenly wasn't
able to choose wireless networks anymore, and even the old fashioned
way via unix groups didn't help either).

So, I'm thinking about a cleaner solution - obviously not dbus, but 9P.

If i understand it correctly, in 9P, the server is in charge of handling
all the access control. So, I can't just write some simple 9P server,
mount it anywhere and magically expect it working just by file
ownerships (by the way: do they have any practical meaning at all ?).

Obviously, the server needs to know who the calling user is and whether
he shall be allowed to access certain items - more precisely whether he
is in the right role right now. And these things could be depending on
other parameters (defined by other parties), eg. when reboot shall only
be allowed when logged-in locally, and no other blocking parts (eg.
important tasks) currently running.

Pretty clear, that these things shouldn't be implemented in each single
service separately, and not every service that might have an influence
here shall have to talk to everybody else.

So, how would a Plan9 solution for these usecases look like ?

In fact, I intend to rewrite network-manager to some 9p-based solution,
so I'd like to discuss this carefully before starting to lennert up
something stupid.


cu



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



  reply	other threads:[~2014-11-29 19:46 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 [this message]
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
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=547A2280.4020407@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).