From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <140e7ec30802121140k6e05465rd13b90f98616650b@mail.gmail.com>
Date: Wed, 13 Feb 2008 04:40:27 +0900
From: sqweek <sqweek@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] 9pfuse adventure
In-Reply-To: <20080208192504.45B4E1E8C5B@holo.morphisms.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <140e7ec30802062352x26255504ha0d54596b954f8b8@mail.gmail.com>
	<20080208192504.45B4E1E8C5B@holo.morphisms.net>
Topicbox-Message-UUID: 517c49c6-ead3-11e9-9d60-3106f5b1d025

On Feb 9, 2008 4:25 AM, Russ Cox <rsc@swtch.com> wrote:
> > provide any facility to attach as a different user. So, I modified the
> > attach strategy to look for a USER environment variable before falling
> > back on getuser(). I've attached the diff, hopefully I got everything.
>
> The name in the attach is almost just a comment.
> What matters is the name used inside the authentication
> protocol.  (The name in the attach is really only there for
> non-authenticated connections.)  So these changes
> shouldn't be necessary.

 Hm, I guess u9fs is misbehaving then?

> This is the problem: you should never be prompted for a
> role=speakfor key.  You should be prompted for a role=client key.
> If that happened correctly then I think things would have just
> worked.  Try pre-loading a role=client key into factotum and
> see if that works better.

 I'm pretty sure I did have a role=client key in factotum in my
previous attempts, added by drawterm (I have a cpu/authserver on my
home network aswell, with the same user/pass/dom as my u9fs.key). I
reran the tests to be sure, the log is below. It turns out I only get
asked for a speakfor key when using my modified USER code, but it's
still the only way I've got a usable connection.
 I had a quick look at u9fs and it does appear to be checking against
the Tattach uname in p9anyattach(), but if that check was failing I
should be getting "authentication failed" not "unknown user".
 Um, but that was a pretty silly place to look anyway. There's only
one place "unknown user" is actually returned, and that is after
uname2user fails in rattach() (which was probably the original reason
for my USER hack).
 I suspect there is no good solution here since if you called
uname2user() on the auth username, every user would connect with the
same permissions (I assume everyone connecting needs an auth key
matching /etc/u9fs.key?). Maybe it would work with tighter coupling
with the auth server? I never fully grasped the reason behind
/etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to
use.

$ 9p read factotum/ctl
key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password?

$ rm `namespace`/wren
$ srv -a sqweek.dnsdojo.org wren
$ 9p ls wren/
9p: mount: unknown user
$ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/
/opt/plan9/src/cmd/o.9p: mount: unknown user

$ rm `namespace`/wren
$ srv sqweek.dnsdojo.org wren
$ 9p ls wren/
9p: mount: unknown user
$ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/
!adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org

-sqweek, thinking he should probably have set inferno up a long time ago