From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3258eb01a201159c8e06f2b23d8b8f4b@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] factotum & invalid entries
From: Lucio De Re <lucio@proxima.alt.za>
Date: Mon,  7 Feb 2005 10:55:04 +0200
In-Reply-To: <65ce4516c890a7cc231be49f75689b0e@ar.aichi-u.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 04404b74-ead0-11e9-9d60-3106f5b1d025

> The above is rough sketch. we should examine more.

If I read your explanation right, you misunderstand something.

	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?

would be valid if the password is correct.

	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=alice !password?

would be invalid if you're not registered as "alice" on sources.

Now, in my case, I always log onto my system as lucio, but as proxima
on sources:

	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=proxima !password?

Unlike pac, I do use the secstore.  But, before I put the "proxima"
entry in the secstore, I used to get prompted for authentication (the
dom= would cause this) and would regularly type "lucio" instead of
"proxima" as well as the wrong password to go with it.  I would then
get, instead of the above:

	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
	key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio !password?

and I'd religiously delkey the second entry before retrying for
exactly the reasons raised by pac and Russ.

Now, I submit that factotum would be right to "delkey" the second
entry as soon as it is aware that the authentication failed.  It
would, by default, overwrite the entry if I changed the password, but
it is not allowed to do so (by design) if I change the username.  I'd
like to stress that there are two conditions here: wrong password and
wrong username.  The first is not a problem, the second is, because
each new username adds an entry, but the first one has precedence.
Reversing the sequence of insertion solves the problem of precedence,
but leaves unwanted rubbish (the username is incorrect) in the
factotum database.  It has one additional side effect, incidental but
critical and Russ addressed that by "invalidating" the record.

In my opinion, that's the wrong approach.  I fail to see a negative
side to factotum deleting the erroneous record rather than flag it
"disabled".  I can see race conditions if different instances of
factotum are involved, possibly denial of service attacks, even, which
is why I asked whether anything would break.  I'm hoping that the
simpler approach is the way to go, anyway.  I am keen to create a log
entry, as, like you, I also like to know where I went wrong.  But
because factotum is required to hide information by design, I fear one
has to learn to minimise errors instead.

++L