Re: [9fans] X11 on 3rd Edition

Re: [9fans] X11 on 3rd Edition

[Russ Cox]

The VNC client we have will be in the next update,
which should happen somewhat soon.

If you need a VNC client before then,
bug me or Richard Miller, depending on
which one you want (I think they're the
same on true color displays; on 8-bit
displays, the one we have uses the 
default RGBV map, while I believe Richard's
changes the color map to the second
edition RGB332 map).

Russ

[9fans] INIT and AUTH - Was: X11 on 3rd Edition

[Lucio De Re]

On Mon, Jul 24, 2000 at 12:03:43AM -0400, Russ Cox wrote:
> 
> The VNC client we have will be in the next update,
> which should happen somewhat soon.
> 
I noticed that there were two changes to /sys/src/cmd/init.c, one to
allow for sysname() as a function, and the other commenting out the
pass() function call.  The former affected - incorrectly, in my
opinion - the name of the environment?device entry by name "sysname",
because of the global search and replacement, the latter I could not
understand, but I restored the call in my particular instance, to give
me 2ed-style behaviour in a CPU server.

Care to include a fix for this in the next update?

And is there a godd reason to keep the "pass()" call out of the way?

Another difference I noticed between 2ed and 3ed is the fact that most
services on a CPU server now run as "none".  As mentioned, that is a
useful security precaution, and would be usefully documented for the
services involved.  Presumably, something along these lines is
happening: if the service is found in /rc/bin/service, it is run under
id "none", if in /rc/bin/service.auth (and elsewhere?), the host id is
used.

On an authentication server (I'm beginning to get a clearer picture of
those dance steps, I think) it would be possible to specify arbitrary
owner ids for services, within the authority granted to the host by
the /lib/ndb/auth file.

Here, I think I start getting confused: who looks at /lib/ndb/auth?
And where there's more than one, which one is used?  I would suggest,
unless I'm missing the point, that there ought to be a single point of
such authority, at least for a single authentication domain.  Is this
at all possible to implement securely?  It would certainly be a bit of
a chicken-and-egg situation where the /lib/ndb/auth file would define
the authentication domain as well as the authentication proxy it
accepted, but additional /lib/ndb/auth files could throw this totally.
I presume Kerberos has some mechanism to resolve this issue?

(Sorry, I'm just an aspiring security consultant, the deeper I dig,
the smaller my field of competence seems to become.)

++L

Re: [9fans] INIT and AUTH - Was: X11 on 3rd Edition

[Russ Cox]

	Another difference I noticed between 2ed and 3ed is the fact that most
	services on a CPU server now run as "none".  As mentioned, that is a
	useful security precaution, and would be usefully documented for the
	services involved.  Presumably, something along these lines is
	happening: if the service is found in /rc/bin/service, it is run under
	id "none", if in /rc/bin/service.auth (and elsewhere?), the host id is
	used.

If its in a directory specified with listen -d, it's
not trusted and runs as none.  Things in a directory
specified with listen -t are trusted, and run as
whoever ran listen.  Listen(8) in my second edition
manual mentions this.  I'm pretty sure it existed then.

	Here, I think I start getting confused: who looks at /lib/ndb/auth?
	And where there's more than one, which one is used?  I would suggest,
	unless I'm missing the point, that there ought to be a single point of
	such authority, at least for a single authentication domain.  Is this
	at all possible to implement securely?  It would certainly be a bit of

The only /lib/ndb/auth that matters is the one
that auth.srv and guard.srv (which run on the
authentication server) see.

Russ

Re: [9fans] INIT and AUTH - Was: X11 on 3rd Edition

[Lucio De Re]

On Wed, Jul 26, 2000 at 12:34:16PM -0400, Russ Cox wrote:
> 
> 	Another difference I noticed between 2ed and 3ed is the fact that most
> 	services on a CPU server now run as "none".  As mentioned, that is a
> 	useful security precaution, and would be usefully documented for the
> 	services involved.  Presumably, something along these lines is
> 	happening: if the service is found in /rc/bin/service, it is run under
> 	id "none", if in /rc/bin/service.auth (and elsewhere?), the host id is
> 	used.
> 
> If its in a directory specified with listen -d, it's
> not trusted and runs as none.  Things in a directory
> specified with listen -t are trusted, and run as
> whoever ran listen.  Listen(8) in my second edition
> manual mentions this.  I'm pretty sure it existed then.
> 
I guess I'll have to look at the sources, but a ps seems adamant
that the owner of all running services is "proxima" on my 2ed
system.  Of course, it may be an installation error on my part,
but a cursory check doesn't disclose anything obviously broken.

> The only /lib/ndb/auth that matters is the one
> that auth.srv and guard.srv (which run on the
> authentication server) see.
> 
I am baffled by that one, courtesy of the newly discovered host ID (I
really understood this even less until now), but I'll do more
investigating before I make a total fool of myself (again).

But maybe somebody can throw me a lifeline: drawterm, which worked
once for me under WinNT, is now rejecting most of my advances with a

	?AS protocol botch: file does not exist

(occasionally it merely hangs, but that's under different circumstances
that can be explained, not unlike the fact that I had it working)
and this message doesn't ring any bells with me.  What's the most
likely origin of this particular error, keeping in mind that the
authentication server is still 2nd edition?

Thanks, everyone.

++L

Re: [9fans] INIT and AUTH - Was: X11 on 3rd Edition

[Lucio De Re]

On Wed, Jul 26, 2000 at 06:59:09PM +0200, Lucio De Re wrote:
> 
> But maybe somebody can throw me a lifeline: drawterm, which worked
> once for me under WinNT, is now rejecting most of my advances with a
> 
> 	?AS protocol botch: file does not exist
> 
...

It turned out to be a missing auth.srv for tcp567 on the auth server.
Having had to think about it, it wasn't quite so hard to get it fixed.

++L