From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pb-smtp21.pobox.com ([173.228.157.53]) by ewsd; Sat Nov 21 03:36:07 -0500 2020
Received: from pb-smtp21.pobox.com (unknown [127.0.0.1])
	by pb-smtp21.pobox.com (Postfix) with ESMTP id 8CE3410C571
	for <9front@9front.org>; Sat, 21 Nov 2020 03:36:00 -0500 (EST)
	(envelope-from unobe@cpan.org)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id
	:from:to:subject:date:mime-version:content-type
	:content-transfer-encoding; s=sasl; bh=tbxCFmtaI+ZlorsHb5yHybe5t
	9A=; b=vODFd16WGlqqqq3HTNYQHH0cZl7ckCPjil1/wEbU00dg2joOKnQy8z0jb
	EcS1kNWbs1eICTvqKtWMt9XUJC70wbCq+JR0Sy+mQ2/GguzekUSocbegsvIgzRtM
	NtPyuaxDhqpUmYmlqM7QDXIT7wtpvNXmO4MqfKRWUgkpk6bIqc=
Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1])
	by pb-smtp21.pobox.com (Postfix) with ESMTP id 7A3E610C570
	for <9front@9front.org>; Sat, 21 Nov 2020 03:36:00 -0500 (EST)
	(envelope-from unobe@cpan.org)
Received: from samwise (unknown [47.34.135.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by pb-smtp21.pobox.com (Postfix) with ESMTPSA id BDBD210C56F
	for <9front@9front.org>; Sat, 21 Nov 2020 03:35:57 -0500 (EST)
	(envelope-from unobe@cpan.org)
Message-ID: <F0F431BFA4A73FCFDAC29257BAF52B1C@smtp.pobox.com>
From: Romano <unobe@cpan.org>
To: 9front@9front.org
Subject: drawterm and factotum with no role attribute
Date: Sat, 21 Nov 2020 00:35:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID:
 93D5D3BC-2BD4-11EB-B117-D609E328BF65-09620299!pb-smtp21.pobox.com
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: shared responsive descriptor XMPP over WEB2.0 grid-oriented strategy 

This perhaps has been answered elsewhere, but I haven't been able to
find it.  I could still be misunderstanding something, but I think
factotum is not documented correctly, or there's a bug in drawterm or
factotum.


In my lib/profile, I had been starting auth/factotum because upon
drawterm'ing in to the system, I didn't see any of my factotum
credentials listed in the output of 'cat /mnt/factotum/ctl', except
for two for the file server (dp9ik and 9psk1).  I looked at different
documentation and websites to determine if I was missing something
simple, and nothing came up about why I would have to start factotum
again in my lib/profile.  I finally decided to cat /mnt/factotum/log,
which shouled a bunch of:

1: no key matches proto=p9sk1 role=server dom?   
1: failure no key matches proto=p9sk1 role=server dom? 
1: no key matches proto=dp9ik role=server dom?   
1: failure no key matches proto=dp9ik role=server dom? 
3: no key matches proto=p9sk1 role=server dom?   
3: failure no key matches proto=p9sk1 role=server dom? 
3: no key matches proto=dp9ik role=server dom?   
3: failure no key matches proto=dp9ik role=server dom? 
4: implicit close due to second start; old attr 'proto=dp9ik role=client dom=9front'

I had a 'key proto=dp9ik dom=9front ...' line in my factotum, and
according to the factotum(4) documentation, that should have sufficed:

          Any key may have a role attribute for restricting how it can
          be used.  If this attribute is missing, the key can be used
          in any role.  The possible values are:

          client
               for authenticating outbound calls

          server
               for authenticating inbound calls

          speakfor
               for authenticating processes whose user id does not
               match factotum's.

I added the specific role= for both 'client' and 'server' (so two
separate line entries in factotum), and that allowed me to
successfully login and to have /mnt/factotum/ctl show all my secstore
factotum lines.

Has anyone come across this themselves?  Am I misunderstanding the
documentation?  Shouldn't 'key proto=dp9ik dom=9front ...' without a
role attribute suffice?