Re: [9fans] Authentication and "emu -d"

Re: [9fans] Authentication and "emu -d"

[presotto]

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

If you want something running as a user that a system can't authenticate
as, you can always start it from cron instead of cpurc or listen.

[-- Attachment #2: Type: message/rfc822, Size: 2892 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: inferno@research.suspicious.org, 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] Authentication and "emu -d"
Date: Mon, 4 Jun 2001 10:51:27 +0200
Message-ID: <20010604105127.C26399@cackle.proxima.alt.za>

Sorry about cross-posting, I'll try not to make a habit of it.

I would like to start Inferno services on my 3ed Plan 9 compute server
using "emu -d".  Two things get in the way:

(a) the ID of the server is "proxima" not "inferno" and that means
that some facilities I previously set up are unavailable.
Authentication is one of these.  If I can track down the
authentication keyfile, I may be able to change its permissions, but
that seems insecure _and_ requires me to put the fileserver in "allow"
mode, a mild pain.  Is there a Plan 9 way of forcing "inferno" to
execute "emu" instead of "proxima", or should I resort to making
"inferno" the compute server owner (Plan 9 AUTH does not run on that
compute server, I still use 2ed AUTH)?

(hm: I did try auth/login - besides requiring to be interactive, it
complains about being run on a compute server :-(

OK, I have now reclassified the compute server so it is owned by
"inferno".  I hope I don't have cause to regret this.  Admittedly, it
does not seem important.

(b) The -d options is wrongly documented: it expects an argument, one
of 0, 1 or 2.  It seems 1 works OK, but I'd like to know what the
other values do.

Also, starting "emu -d1" from cpurc seems to do ugly things to the
keyboard/input interface, the console no longer echoes.  And output
should probably be redirected to a log file, too.  Something for the
manual pages?

++L

Re: [9fans] Authentication and "emu -d"

[forsyth]

>>PS: Re-reading your answer, it would seem that "emu" has two closely
>>coupled functions that could do with some decoupling, namely "dis"
>>emulation and graphics (I'm reading between the lines, I get the
>>feeling "emu -d"'s failing lies in the management of interaction with
>>its environment).  Perhaps discarding the graphics baggage is an
>>option?  Sounds tough to do, for little gain, but there's something to
>>be said for text-only interactions, and Plan 9 ain't going that way,
>>perhaps Inferno can.

no, not at all, that's easy to sort out.
it's the authentication that worries me.

Re: [9fans] Authentication and "emu -d"

[Lucio De Re]

On Mon, Jun 04, 2001 at 11:06:18AM +0100, forsyth@caldo.demon.co.uk wrote:
> 
> no, not at all, that's easy to sort out.
> it's the authentication that worries me.

Silly me, I should have figured it out.

In other mail, you advised against using "emu" setuid(root).
Thinking aloud, this would require logging in to emu rather than
wm/logon so that emu could drop its rights as early as possible.
Another option might be to drop rights (to nobody, or thereabouts)
immediately, and regain them for the prompt (ugly, the user is
quite literally in Limbo <grin> in between, but emuinit.dis could
solve that), switching to the logged in user thereafter.

I believe this is possible with saved-ids (uglier and uglier) but
I'm hardly the expert.

How one does this in Plan 9 is not clear to me, but if Plan 9 does
not provide the facility (possibly only on compute servers), then
it's a serious shortcoming.

"emu -d" under Plan 9 is OK, as long as it can match the native
user space.  But that parallels the Unix model quite closely,
without the intrusion of "nobody/none" as a temporary measure
because of its background only operation.

To answer Digby Tarvin's question, then, Inferno (under Plan 9)
should be targetted for installation on a CPU server and effectively
provide only very limited services from workstations to potential
clients.  Under other OSs, parallel models of operations may apply
(beware of "System" and "Administrator" under WinNT (I think 2k is
the same) which are scary concepts).

Certainly, the concept of hosted users, in a distributed, hosted
processing environment, is a touch problematic, and that's clearly
an understatement.  Certainly it is unavoidable that the Inferno
user space has to be a subset of the host's, and in a heterogenous
environment that's interesting at the very least (nightmarish would
be closer to the truth).

++L

Re: [9fans] Authentication and "emu -d"

[forsyth]

that really is inferno-specific, so we'll answer it in detail on that list.

i'd thought we left -d deliberately undocumented
but i see it is there in the manual page after all.

>>Also, starting "emu -d1" from cpurc seems to do ugly things to the
>>keyboard/input interface, the console no longer echoes.  And output
>>should probably be redirected to a log file, too.  Something for the

this is just the superficial reason i intended to leave it
undocumented.  it was left in the code because one group might have
been using it at the time, under Solaris, for which it was originally
hacked in (where hacked is the right description), in a hurry.  i
suppose you could wonder: if it can't cope with the console correctly,
how is it likely to do on the hard bits?  that gets close to the
truth.  it does only what it was intended to do,
but doesn't go far enough, even though they did hire a web page designer!
anyway, someone will send more about it to the inferno list later.

Re: [9fans] Authentication and "emu -d"

[Lucio De Re]

On Mon, Jun 04, 2001 at 10:12:34AM +0100, forsyth@caldo.demon.co.uk wrote:
> 
> that really is inferno-specific, so we'll answer it in detail on that list.
> 
> i'd thought we left -d deliberately undocumented
> but i see it is there in the manual page after all.
> 
Security by obscurity (or, in this case, "d" for disinformation :-)
You'll eventually be pleased to have been caught with your pants down,
the idea is good, definitely in the list of nice-to-haves.

> >>Also, starting "emu -d1" from cpurc seems to do ugly things to the
> >>keyboard/input interface, the console no longer echoes.  And output
> >>should probably be redirected to a log file, too.  Something for the
> 
> this is just the superficial reason i intended to leave it
> undocumented.  it was left in the code because one group might have
> been using it at the time, under Solaris, for which it was originally
> hacked in (where hacked is the right description), in a hurry.  i
> suppose you could wonder: if it can't cope with the console correctly,
> how is it likely to do on the hard bits?  that gets close to the
> truth.  it does only what it was intended to do,
> but doesn't go far enough, even though they did hire a web page designer!
> anyway, someone will send more about it to the inferno list later.


Well, _I'm_ using it, on a CPU server that sits practically headless
(and could be headless if I had more faith - Microsoft keep rattling
my faith and it bleeds over all the other OSs in my life :-)

It will be just fine the way it is, and as soon as "I can get my
pennies together for the source licence (TM)" I'll see if I can help
smooth some of the wrinkles out.

Just of the record , would "emu -d1 </dev/null >/dev/null >[2=1]"
break, or can I safely try it without losing what little mind I still
have left?

(My answer to that, in your shoes, might be "you tell us", but I'm
going to need some encouragement to tackle such obviously tangential
operations, I don't do elective surgery :-)

++L

PS: Re-reading your answer, it would seem that "emu" has two closely
coupled functions that could do with some decoupling, namely "dis"
emulation and graphics (I'm reading between the lines, I get the
feeling "emu -d"'s failing lies in the management of interaction with
its environment).  Perhaps discarding the graphics baggage is an
option?  Sounds tough to do, for little gain, but there's something to
be said for text-only interactions, and Plan 9 ain't going that way,
perhaps Inferno can.

[9fans] Authentication and "emu -d"

[Lucio De Re]

Sorry about cross-posting, I'll try not to make a habit of it.

I would like to start Inferno services on my 3ed Plan 9 compute server
using "emu -d".  Two things get in the way:

(a) the ID of the server is "proxima" not "inferno" and that means
that some facilities I previously set up are unavailable.
Authentication is one of these.  If I can track down the
authentication keyfile, I may be able to change its permissions, but
that seems insecure _and_ requires me to put the fileserver in "allow"
mode, a mild pain.  Is there a Plan 9 way of forcing "inferno" to
execute "emu" instead of "proxima", or should I resort to making
"inferno" the compute server owner (Plan 9 AUTH does not run on that
compute server, I still use 2ed AUTH)?

(hm: I did try auth/login - besides requiring to be interactive, it
complains about being run on a compute server :-(

OK, I have now reclassified the compute server so it is owned by
"inferno".  I hope I don't have cause to regret this.  Admittedly, it
does not seem important.

(b) The -d options is wrongly documented: it expects an argument, one
of 0, 1 or 2.  It seems 1 works OK, but I'd like to know what the
other values do.

Also, starting "emu -d1" from cpurc seems to do ugly things to the
keyboard/input interface, the console no longer echoes.  And output
should probably be redirected to a log file, too.  Something for the
manual pages?

++L