[9fans] Authentication questions

[9fans] Authentication questions

[Brian L. Stuart]

Once again, I find myself in the unhappy, but familiar,
place of being befuddled by security/authentication.
Backstory: After fighting with flaky disk drives and
scary RAID controllers, I have a system set up as a
CPU server running fossil+venti, and I want to play
around with it acting as a file server in a mixed
environment.  I've got authentication set up enough
so that I can drawterm in.  But:

If /bin/service/tcp564 has exec /bin/exportfs -s
   On the cpu server: 9fs tcp!127.1 works as if
     I am none--can't write.
   Using P9P: 9 srv -a xxx.xxx.xxx.xxx test
     reports rx: exportfs: authentication not required
     and upon mounting it behaves as if I'm none

If /bin/service/tcp564 has exec /bin/exportfs -s -a
   On the cpu server: 9fs tcp!127.1 reports:
      srv tcp!127.1: mount failed: EOF receiving fversion reply
   Using P9P: 9 srv -a xxx.xxx.xxx.xxx test
      reports: srv: Tversion: bad length in 9P2000 message header

Factotum is running in both cases.  What am I doing
wrong?  I'm trying to mount the server's file system
and authenticate in.  I must be missing something
fundamental.

Thanks,
BLS

Re: [9fans] Authentication questions

[Christian Kellermann]

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

* Brian L. Stuart <blstuart@bellsouth.net> [080505 20:50]:
> Once again, I find myself in the unhappy, but familiar,
> place of being befuddled by security/authentication.
> Backstory: After fighting with flaky disk drives and
> scary RAID controllers, I have a system set up as a
> CPU server running fossil+venti, and I want to play
> around with it acting as a file server in a mixed
> environment.  I've got authentication set up enough
> so that I can drawterm in.  But:
> 
> If /bin/service/tcp564 has exec /bin/exportfs -s
>    On the cpu server: 9fs tcp!127.1 works as if
>      I am none--can't write.
>    Using P9P: 9 srv -a xxx.xxx.xxx.xxx test
>      reports rx: exportfs: authentication not required
>      and upon mounting it behaves as if I'm none
> 
> If /bin/service/tcp564 has exec /bin/exportfs -s -a
>    On the cpu server: 9fs tcp!127.1 reports:
>       srv tcp!127.1: mount failed: EOF receiving fversion reply
>    Using P9P: 9 srv -a xxx.xxx.xxx.xxx test
>       reports: srv: Tversion: bad length in 9P2000 message header
> 
> Factotum is running in both cases.  What am I doing
> wrong?  I'm trying to mount the server's file system
> and authenticate in.  I must be missing something
> fundamental.

You did set up a user in fossil with fossilcons(8) right?

Kind regards,

Christian

-- 
You may use my gpg key for replies:
pub  1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] Authentication questions

[Brian L. Stuart]

From: Christian Kellermann <Christian.Kellermann@nefkom.net>
>You did set up a user in fossil with fossilcons(8) right?

Yes.  That's the user I'm drawterm'd in as and the
one I'm using as the uname option when mounting
using P9P.

Thanks,
BLS

Re: [9fans] Authentication questions

[Brian L. Stuart]

> Once again, I find myself in the unhappy, but familiar,
> place of being befuddled by security/authentication.
> ...

I know it's bad form to reply to your own question,
but I've gotten a bit farther.  I realized that
/bin/service/tcp564 isn't the right way to go about
it.  After a good slap on the forehead, I am now
starting listen from fscons.  I'm now able to 9fs
on the server and it works like I expect.  However,
I still have no joy from P9P.  The command:

9 srv -a xxx.xxx.xxx.xxx test

triggers factotum to prompt for the user and password
but then gives the error:

authdial: Connection refused
srv: authproxy: auth_proxy rpc: p9any client get tickets: p9sk1: gettickets:
Connection refused

Obviously, I've still got something not right in the
authentication world.  Any ideas?

Thanks,
BLS

Re: [9fans] Authentication questions

[Steve Simon]

try some debug in factotum perhaps (-d)?

I have had great success debugging auth problems between plan9 servers
using auth/debug - however I don't know if this exists on p9p.

-Steve

Re: [9fans] Authentication questions

[a]

// authdial: Connection refused
// srv: authproxy: auth_proxy rpc: p9any client get tickets: p9sk1: gettickets:
// Connection refused

are you sure that both your auth server is running (look for results
from 'ps | grep keyfs') and that you're running the network listener
for it (service.auth/tcp567)? the "connection refused" says it's just
not getting in, most likely because you're not listening on tcp567.
note that the trusted listeners are started separately from the
others, and not in the default config. see the -t argument to
listen(8) and the comments in /bin/cpurc.
anthony

Re: [9fans] Authentication questions

[Brian L. Stuart]

> are you sure that both your auth server is running (look for results
> from 'ps | grep keyfs') and that you're running the network listener
> for it (service.auth/tcp567)? the "connection refused" says it's just

They are.  As it turns out, it was a combination of operator
error and misleading documentation.  I had not put an appropriate
entry in /usr/local/plan9/ndb/local.  Instead, I had specified
the auth server's IP address in a -a argument to factotum.
It looked from the man page that would work, but it doesn't.
In fact the authaddr variable set to that argument doesn't
appear to ever get used anywhere.  Anyway, the moral of the
story is to put the entry in ndb/local and not rely on the
-a option to factotum.

As long as I'm at it, though, I've got a question about listen.
It's filling a rather large logfile with lots of address in
use errors.  As I look into things, it appears that I'm starting
listen both in /bin/cpurc and in /cfg/phantom/cpurc with the
latter specifying the -t option.  That definitely seems to
be one too many.  It looks from what I've got that I should
comment out the one in /bin/cpurc.  What is the convention
on that?

Thanks for all the suggestions,
BLS

Re: [9fans] Authentication questions

[Brian L. Stuart]

> As long as I'm at it, though, I've got a question about listen.
> It's filling a rather large logfile with lots of address in
> use errors.  As I look into things, it appears that I'm starting
> listen both in /bin/cpurc and in /cfg/phantom/cpurc with the
> latter specifying the -t option.  That definitely seems to
> be one too many.  It looks from what I've got that I should
> comment out the one in /bin/cpurc.  What is the convention
> on that?

One of these days, I'm going to get this right...
I meant to say /cfg/phantom/cpustart which gets run after
listen is started in /bin/cpurc.  What is the usual way
to do this?

Thanks,
BLS

Re: [9fans] Authentication questions

[a]

I'm not sure about the "usual" way, but I've got the
listens in cpurc commented out and rely only on
entries in /cfg/whatever/cpustart.

Does your cpustart listen specify -d as well as -t?
It looks like giving only -t should make it not try
(or re-try in your case) the non-trusted ones.
Anthony

Re: [9fans] Authentication questions

[Brian L. Stuart]

> I'm not sure about the "usual" way, but I've got the
> listens in cpurc commented out and rely only on
> entries in /cfg/whatever/cpustart.

Sounds like there are several ways people handle this.
For now at least, I'm going to go with my initial
instinct and leave the listens commented out in cpurc
and use the ones in cpustart.  Doing that has stopped
the issue reported in the logging.

BLS

Re: [9fans] Authentication questions

[erik quanstrom]

> As long as I'm at it, though, I've got a question about listen.
> It's filling a rather large logfile with lots of address in
> use errors.  As I look into things, it appears that I'm starting
> listen both in /bin/cpurc and in /cfg/phantom/cpurc with the
> latter specifying the -t option.  That definitely seems to
> be one too many.  It looks from what I've got that I should
> comment out the one in /bin/cpurc.  What is the convention
> on that?

you need to use a different directory if you're starting a second
listen with the -t option.  e.g. /rc/bin/service.auth.  there shouldn't
be any duplication in scripts (save one starting in !) between the
normal and the -t directories.

not sure if this helps, but i perfer the old style bit switch statement.
i tacked on a bit of our cpurc for reference.

- erik

fn external{
	bind -b '#l1' /net.alt
	bind -b '#I1' /net.alt
	ip/ipconfig -x /net.alt -g 12.51.113.1 ether /net.alt/ether1 $1 /123
	ndb/cs -x /net.alt -f /lib/ndb/external
	switch($2){
	case recursive
		ndb/dns -sx /net.alt -f /lib/ndb/external
	case notrecursive
		ndb/dns -Rrsx/net.alt -f /lib/ndb/external
	}
}

echo cpurc $sysname
switch ($sysname) {
case tyty
	timesync $time

	ndb/dns -s
	ip/dhcpd
	ip/tftpd

	auth/keyfs -wp
	auth/secstored >/dev/null >[2=1]
	auth/cron >>/sys/log/cron >[2=1] &
	aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service il
	aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service tcp

	external 12.51.113.2 none
	aux/listen -q -t /rc/bin/service.extauth -d /rc/bin/service.ext /net.alt/tcp

[...]