Re: [9fans] a few Q's regarding cpu/auth server

[Corey <corey@bitworthy.net>]

On Thursday 06 August 2009 21:19:05 lucio@proxima.alt.za wrote:
<snip>
> If you think it's worth it, then you need to put your money where your
> mouth is.
>

Like I said:

"Anyhow... I guess there's no reason to argue/debate! Looks like I
have some options"

... and later:

"[...] plus, I've already been provided with solutions from which I can roll
my  own."


> You are forgetting that the cost of security must be commensurate with
> the risk.
>

I'm forgetting what?

"The Plan 9 way of thinking (wrt the security of physical terminal access)
completely undermines, or somehow fails to recognize, the very real fact
that there is always a cost/risk effort/reward equation at play."


> When Plan 9 is popular enough for random visitors to desire to crack it,
> then the extra security will be worth the extra effort.  Until then, we can
> all save ourselves the bother
>

Sheesh:

"I think the actual root of the situation, is simply that Plan 9 currently
tends to reside within domains with much more strict and secure
or trustworthy environments vs. being prevalent within the sphere of
the great unwashed masses of the industry where strong physical
security is either unobtainable, unaffordable, and/or unreliable at best."


> Am I remembering wrong that 2nd Edition had password control on CPU
> servers?  I missed it briefly, then forgot about it.  Oh, yes, the
> change arose from the new security infrastructure, Bell Labs did not
> have the resources to port it so they abandoned it.  I adapted the old
> password check for something else, but what with NVRAM's failings and
> the effort involved, I never tried to get the CPU server to have a
> secured console.
>

I mention there are reasonable use-cases for a secured console on Plan 9
servers, and everybody attempts to show me why such a concept is completely
unnecessary.... but in fact it's simply a matter of Bell Labs and others not
having the resources to implement it in later editions.  And in fact it was
a feature that previously existed.


> PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU
> server would be almost all that's needed, just like in Unix.  So this
> discussion has been quite unnecessary.
>

Cool, it's a total no-brainer to implement; the discussion can end now.