> The following is all hypothetical. I'm curious about how people
> think auth(2)/factotum(4) could be adapted to support the use
> case ...
>
> factotum was intended to handle the authentication dance on behalf
> of network apps. But in the case of things like IMAP, it really
> just stores the
i'd like to see the auth server do more of the work.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M269a6e45351ce1fc554237ae
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
And work under p9p. Me too! Plug in a proper X-based WM and I can get
some performance out of my rather dated equipment again.
Lucio.
On 1/24/20, Lyndon Nerenberg wrote:
> The following is all hypothetical. I'm curious about how people
> think auth(2)/factotum(4) could be adapted to support
The following is all hypothetical. I'm curious about how people
think auth(2)/factotum(4) could be adapted to support the use
case ...
factotum was intended to handle the authentication dance on behalf
of network apps. But in the case of things like IMAP, it really
just stores the client's
Good afternoon,
On Sat, Nov 29, 2014 at 08:46:08PM +0100, Enrico Weigelt, metux IT consult
wrote:
snip
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
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.
For this sort of functionality the
On Mon, Dec 01, 2014 at 08:08:04PM -0800, erik quanstrom wrote:
On Sat, 29 Nov 2014 20:46:08 +0100, Enrico Weigelt, metux IT consult wrote:
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
On 12/02/2014 10:40 AM, plann...@sigint.cs.purdue.edu wrote:
On Mon, Dec 01, 2014 at 08:08:04PM -0800, erik quanstrom wrote:
On Sat, 29 Nov 2014 20:46:08 +0100, Enrico Weigelt, metux IT consult wrote:
So, how would a Plan9 solution for these usecases look like ?
In fact, I intend to rewrite
if i understand correctly, the basic issues you're trying to solve (beyond
authentication), are delegation and authorization. because you're
targeting non-plan9 environments, my comments will be focused on those
environments.
any decent IT with heterogeneous OS environments will have a
9love is tough love.
On Tue, Dec 2, 2014 at 7:40 AM, plann...@sigint.cs.purdue.edu wrote:
On Mon, Dec 01, 2014 at 08:08:04PM -0800, erik quanstrom wrote:
On Sat, 29 Nov 2014 20:46:08 +0100, Enrico Weigelt, metux IT consult
wrote:
So, how would a Plan9 solution for these usecases look like
On 02.12.2014 10:50, Richard Miller wrote:
For this sort of functionality the computer needs to be running as
a plan 9 cpu server, not a terminal in which by definition hostowner
controls everything.
Somewhere in /contrib there is a patch which makes a few changes to
the cpu kernel to
On 02.12.2014 16:40, plann...@sigint.cs.purdue.edu wrote:
To be fair, he's not talking about using Plan 9, just leveraging something
factotum-like under Linux.
Exactly.
I wanna get rid of dbus and polkit, replace it by something 9P-based.
Before hacking up something on my own, I'm just
On Mon, Dec 01, 2014 at 09:00:46AM +0200, lu...@proxima.alt.za wrote:
The guy in front of the console should authenticate as a normal user
and then only be allowed to access his own environment (no direct
control over hw, etc).
The guy is not in front of the console, he has physical and
But, IMHO, this is precisely the difference between Unix and Plan9.
The important difference is that in Unix the terminal, specially
graphics terminals like X servers, have to be trusted to be in good
hands - which cannot be enforced. When you look at NFS, for example,
a trusted network node
The guy in front of the console should authenticate as a normal user
But you do authenticate to Plan 9 as a normal user. On one node you're
the hostowner, but to the *system* you authenticate as a normal user.
One guy on here lately was actually attaching to his fileserver as
none.
A system is
On 01.12.2014 11:38, tlaro...@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
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
The guy in front of the console should authenticate as a normal user
and then only be allowed to access his own environment (no direct
control over hw, etc).
The guy is not in front of the console, he has physical and
therefore unrestricted access to all the resources in the terminal. A
CPU
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
So, how would a Plan9 solution for these usecases look like ?
plan 9 doesn't pretend that the hostowner doesn't fully control the box,
so it doesn't attempt to prevent the hostowner from e.g. turning wireless
on and off.
- erik
On 29.11.2014 20:46, erik quanstrom wrote:
Hi,
So, how would a Plan9 solution for these usecases look like ?
plan 9 doesn't pretend that the hostowner doesn't fully control the box,
so it doesn't attempt to prevent the hostowner from e.g. turning wireless
on and off.
In my scenario, I'm
In my scenario, I'm (more precisely: the account I'm using) not the
hostowner, just a plain user - in Unix terms: non-root). But that
account has the special privileges of controlling the network
connections. Other accounts may only choose from a predefined list
of connections.
if you've
to do a comparative analysis of the functions it makes sense to know one
side very well. i found it easier to understand factotum and compare the
others to factotum. to me SASL is more like the functions of factotum's rpc
and proto files. Window's Local Security Authority (LSA) combined with
Factotum (Russ may correct me) is modelled on SSH's agent. The SASL
type functionality resides in the servers that use factotum, so I'd
say the differences are quite significant.
There is a paper on Plan 9 security that makes very interesting
reading.
do you have a reference for this
do you have a reference for this claim?
The claim that Russ first produced a utility called agent, or that the
server logic resides in servers? I may have summarised the protocol
poorly, but factotum is an intermediary, neither client seeking
authentication, nor server validating credentials.
Hi folks,
I've got the impression that there're some similarities between SASL
(saslauthd) and Factotum - at least at the point that both are
offloading actual authentication handshakes to a separate service.
But I have to admit that I didn't have done a deeper analysis of
these two.
Could
I've got the impression that there're some similarities between SASL
(saslauthd) and Factotum - at least at the point that both are
offloading actual authentication handshakes to a separate service.
But I have to admit that I didn't have done a deeper analysis of
these two.
Could anybody
Could anybody with deeper insight perhaps give some detailed
comparison between them ?
Factotum (Russ may correct me) is modelled on SSH's agent. The SASL
type functionality resides in the servers that use factotum, so I'd
say the differences are quite significant.
There is a paper on Plan 9
28 matches
Mail list logo
