Re: [9fans] pwd

Re: [9fans] pwd

[forsyth]

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

it's worth noting that although the user isn't authenticated, in the sense
of checking a password (though you could add it if need be, i suppose),
disk/kfs does still check permissions against the user name
and associated groups, reducing the scope for accidents.


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

To: 9fans@cse.psu.edu
Cc: 
Subject: Re: [9fans] pwd
Date: Fri, 17 Aug 2001 12:04:10 -0400 (EDT)
Message-ID: <200108171604.MAA16468@augusta.math.psu.edu>

In article <cej-1010816162318.A01284@cejchan.gli.cas.cz> you write:
>Hmm... sounds like there is no way how to authenticate a user on a singlr
>plan9 machine, am I right?

Yup, that's basically it.

	- Dan C.

Re: [9fans] pwd

[Dan Cross]

In article <20010817164416.DF40C199E9@mail.cse.psu.edu> you write:
>it's worth noting that although the user isn't authenticated, in the sense
>of checking a password (though you could add it if need be, i suppose),
>disk/kfs does still check permissions against the user name
>and associated groups, reducing the scope for accidents.

True!  But in the same vein, one can counter that by doing,
``disk/kfscmd allow''

However, as you point out, that's not the default, and the default rules
do prevent quite a bit of accidental migraines.

	- Dan C.

Re: [9fans] pwd

[Dan Cross]

In article <cej-1010816162318.A01284@cejchan.gli.cas.cz> you write:
>Hmm... sounds like there is no way how to authenticate a user on a singlr
>plan9 machine, am I right?

Yup, that's basically it.

	- Dan C.

Re: [9fans] pwd

[pac]

>> In article <cej-1010815163141.A02421@cejchan.gli.cas.cz> you write:
>> >It is a single machine running plan9 in the whole LAN; thus it should
>> >serve everything: cpu, file, auth ...  Do I have to configure auth
>> >services manually?
>> 
>> Well, if it's set up as a terminal, and using the default
>> /rc/bin/termrc, then it won't start the auth services, and you'd have
>> to configure it otherwise.  Likewise with serving kfs.
>> 
>> If it's the only plan 9 machine on the network, you have a chicken and
>> egg problem when it boots up; it's the kernel that asks for your
>> password and expects to be able to talk to the auth server to validate
>> it.  But, if you haven't started the auth server, and you clearly
>> haven't since you haven't started any user processes yet, it'll have
>> nothing to validate against.
>> 
>> CPU servers get around this by either not asking for a password at all
>> and having a local KFS file system (started by the kernel) off of which
>> they'll start the auth server, or, if talking to a file server, by
>> timing out and saying, ``okay, I'll use the key that's in my nvram to
>> authenticate myself to the file server....'' (the file server also
>> knows it's own key, so that's okay) and then starting up the auth
>> server.
>> 
>> Terminals expect that an auth server already is running, and will fail
>> to start if they can't get a valid password (unless they're configured
>> to start up standalone, using kfs, which again ist started by the
>> kernel, in which case we're back where we started, where whatever
>> password you enter is essentially meaningless, thus the idea of
>> changing it is also meaningless).
>> 
>> Does that make sense?  (Other 9fans, did I make any mistakes in my
>> description above?  Please feel free to correct me; I don't want to
>> spread falsehoods out of ignorance.  :-)
>> 
>> 	- Dan C.
>> 
>> 


Hmm... sounds like there is no way how to authenticate a user on a singlr plan9 machine, am I right?

Re: [9fans] pwd

[forsyth]

>>[in 2nd edition, to select self as auth server] one of 0.1.0.0 or 0.0.1.0 or whatever or how to make it work.

it needed to be non-zero or panic ensued.   with the current system,
i set auth=cpu-server-name and it doesn't need to time out
(the listeners not having been started, the connection is reset immediately).
i don't think i did anything special to cpurc to do that.

Re: [9fans] pwd

[Dan Cross]

In article <20010815184409.H29491@cackle.proxima.alt.za> you write:
>This does baffle me.  I'm sure 2ed had the option to tell the
>AUTH server (CPU server, to be exact) that there it was
>authoritative, without waiting for a timeout.  But I could
>never figure out if it was 0.0.0.0 (which caused a panic) or
>one of 0.1.0.0 or 0.0.1.0 or whatever or how to make it work.

Hmm, I'm not sure; I never really used 2nd ed because at the time,
I couldn't afford it, and when I could afford it, it wasn't available
anymore.  c'est la vie.

	- Dan C.

Re: [9fans] pwd

[Lucio De Re]

On Wed, Aug 15, 2001 at 12:33:59PM -0400, Dan Cross wrote:
> 
> CPU servers get around this by either not asking for a password at all
> and having a local KFS file system (started by the kernel) off of which
> they'll start the auth server, or, if talking to a file server, by
> timing out and saying, ``okay, I'll use the key that's in my nvram to
> authenticate myself to the file server....'' (the file server also
> knows it's own key, so that's okay) and then starting up the auth
> server.
> 
This does baffle me.  I'm sure 2ed had the option to tell the
AUTH server (CPU server, to be exact) that there it was
authoritative, without waiting for a timeout.  But I could
never figure out if it was 0.0.0.0 (which caused a panic) or
one of 0.1.0.0 or 0.0.1.0 or whatever or how to make it work.

Pity, because I'm sure I had it all working (2ed, that was)
until I lost the NVRAM and now I have to press enter for each
IP detail _and_ wait for the timeout and I have no idea how to
put that Humpty-Dumpty together again.

++L

Re: [9fans] pwd

[Dan Cross]

In article <cej-1010815163141.A02421@cejchan.gli.cas.cz> you write:
>It is a single machine running plan9 in the whole LAN; thus it should
>serve everything: cpu, file, auth ...  Do I have to configure auth
>services manually?

Well, if it's set up as a terminal, and using the default
/rc/bin/termrc, then it won't start the auth services, and you'd have
to configure it otherwise.  Likewise with serving kfs.

If it's the only plan 9 machine on the network, you have a chicken and
egg problem when it boots up; it's the kernel that asks for your
password and expects to be able to talk to the auth server to validate
it.  But, if you haven't started the auth server, and you clearly
haven't since you haven't started any user processes yet, it'll have
nothing to validate against.

CPU servers get around this by either not asking for a password at all
and having a local KFS file system (started by the kernel) off of which
they'll start the auth server, or, if talking to a file server, by
timing out and saying, ``okay, I'll use the key that's in my nvram to
authenticate myself to the file server....'' (the file server also
knows it's own key, so that's okay) and then starting up the auth
server.

Terminals expect that an auth server already is running, and will fail
to start if they can't get a valid password (unless they're configured
to start up standalone, using kfs, which again ist started by the
kernel, in which case we're back where we started, where whatever
password you enter is essentially meaningless, thus the idea of
changing it is also meaningless).

Does that make sense?  (Other 9fans, did I make any mistakes in my
description above?  Please feel free to correct me; I don't want to
spread falsehoods out of ignorance.  :-)

	- Dan C.

Re: [9fans] pwd

[pac]

>> In article <cej-1010814134008.A02245@cejchan.gli.cas.cz> you write:
>> >running passwd on a standalone box I got:
>> >
>> >term% passwd
>> >passwd: protocol botch: cs: can't translate address(net!$auth!ticket)
>> >
>> >I tried to rtfmanpage (cs) and played with ndb/csquery,
>> >but the only thing that cs resolves is net!cejchan!9fs
>> 
>> Is the machine configured as a standalone _terminal_ as opposed
>> to a CPU server?  If so, don't worry about it; there's no real
>> point in changing one's password since you're not running the
>> authentication services.
>> 
>> 	- Dan C.
>> 
>> 

It is a single machine running plan9 in the whole LAN; thus it should serve everything: cpu, file, auth ...
Do I have to configure auth services manually?

Thanks, regards, Peter.

--
Peter A Cejchan
biologist
Acad. Sci., Prague, CZ
<cej at cejchan dot gli dot cas dot cz>

Re: [9fans] pwd

[pac]

>> Have a look at http://plan9.bell-labs.com/wiki/plan9/9 to
>> see how names like net!$auth!ticket get translated.
>> 
>> Russ
>> 

I've read this page several times even before, however, I can't find there any stuff related to cs:
it's all about ndb. Am I missing  something?


Regards, Peter.
--
Peter A Cejchan
biologist
Acad. Sci., Prague, CZ
<cej at cejchan dot gli dot cas dot cz>

Re: [9fans] pwd

[Russ Cox]

Have a look at http://plan9.bell-labs.com/wiki/plan9/9 to
see how names like net!$auth!ticket get translated.

Russ

Re: [9fans] pwd

[Dan Cross]

In article <cej-1010814134008.A02245@cejchan.gli.cas.cz> you write:
>running passwd on a standalone box I got:
>
>term% passwd
>passwd: protocol botch: cs: can't translate address(net!$auth!ticket)
>
>I tried to rtfmanpage (cs) and played with ndb/csquery,
>but the only thing that cs resolves is net!cejchan!9fs

Is the machine configured as a standalone _terminal_ as opposed
to a CPU server?  If so, don't worry about it; there's no real
point in changing one's password since you're not running the
authentication services.

	- Dan C.

[9fans] pwd

[pac]

Hi,

running passwd on a standalone box I got:

term% passwd
passwd: protocol botch: cs: can't translate address(net!$auth!ticket)

I tried to rtfmanpage (cs) and played with ndb/csquery,
but the only thing that cs resolves is net!cejchan!9fs

TIA, Peter.

--
Peter A Cejchan
biologist
Acad. Sci., Prague, CZ
<cej at cejchan dot gli dot cas dot cz>