From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 26802 invoked from network); 30 Sep 2021 21:50:07 -0000
Received: from 4ess.inri.net (216.126.196.42)
  by inbox.vuxu.org with ESMTPUTF8; 30 Sep 2021 21:50:07 -0000
Received: from rpi1.z0.is ([31.37.164.83]) by 4ess; Thu Sep 30 17:42:57 -0400 2021
Message-ID: <A72B92C315D464F7DE8A24581FA3CCAF@z0.is>
From: <me@josuah.net>
Date: Thu, 30 Sep 2021 21:32:08 +0200
To: 9front@9front.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: stateless framework self-signing API-scale solution 
Subject: [9front] no more auth in exportfs(4)?
Reply-To: 9front@9front.org
Precedence: bulk

I am trying to PXE boot to my raspberry pi 2, currently acting as
fs, auth and cpu. I boot a laptop over PXE and it works all good,
but the laptop does not have write access to its filesystem.

By running "allow" on /srv/hjfs.cmd, I can write, and the files
are created as user none, the same user as exportfs.

Starting with commit 27a83106f4b5b68d77afa8f800d92398163a7043 there
is no more authentication on exportfs:

-	if(na == nil && doauth){
-		/*
-		 * We use p9any so we don't have to visit this code again, with the
-		 * cost that this code is incompatible with the old world, which
-		 * requires p9sk2. (The two differ in who talks first, so compatibility
-		 * is awkward.)
-		 */
-		ai = auth_proxy(0, auth_getkey, "proto=p9any role=server %s", keyspec);
-		if(ai == nil)
-			fatal("auth_proxy: %r");
-		if(nonone && strcmp(ai->cuid, "none") == 0)
-			fatal("exportfs by none disallowed");
-		if(auth_chuid(ai, nsfile) < 0)
-			fatal("auth_chuid: %r");
-		else {	/* chown network connection */
-			Dir nd;
-			nulldir(&nd);
-			nd.mode = 0660;
-			nd.uid = ai->cuid;
-			dirfwstat(0, &nd);
-		}
-		putenv("service", "exportfs");
-	}

auth_chuid() is what I think am after: writing to capuse.
The long-ish comment seens ti refer to the changes described in
/sys/doc/auth.ps that put factotum as main auth agent.

Is that feature of plan9 moving somewhere else? Am I having the
wrong approach? If it is a work in progress?

I will try a patch adding auth code into exportfs in the meantime,
that will be a good exercise anyway.