Re: [9fans] factotum & invalid entries

[Lucio De Re <lucio@proxima.alt.za>]

> I believe factotum does not keep clear password if proto=p9sk1
> Then log entry will be useless even if the log shows the key.
> If authentication failed and attribute value list is right except
> password,
> then we should retry with a new password.
>
That, unless I misunderstand Russ's comment, is already the case:
factotum will re-prompt if an attempted connection fails because of an
authentication error.  It is when a different username is submitted
that problems arise in the old style of operation where entries were
appended to the factotum database.

> Current factotum is inconvenient if the order is matter.

Correct: responding to a factotum request with a new username causes a
new entry to be created, whereas if only the password is different,
the previous entry is replaced.  The earlier entry, now with an
invalid username, will have priority over a subsequent correct entry,
invalidating the entire procedure (again, as things used to be).

> I think my proposal is one of idea to resolve the problem.
> Of course if we failed in authentication, then disabled flag will be put
> automatically at the beginning of the attribute value list, and if we
> succeed
> in next authentication the attribute value list is automatically
> replaced by new
> one without changing the order.
>
The point you raised was that you actually want to retain the error
entry for inspection which in my opinion causes more difficulty than
is justified.  A middle ground is to log the erroneous entry in the
same form as would be displayed by looking at the factotum database
and then discard it altogether.  This ought to satisfy your curiosity
and allow us to append new entries rather than prepend them, at the
same time removing the need for the "disabled" attribute.

Once we start treating sequence as significant (we already do, of
course), I think we tread on very thin ice.  Russ's idea of additional
attributes is a sound one to resolve possible ambiguities, rather than
rely on position in the database with all the associated risks.  For
example, what happens if I delete a key and resubmit it instead of
merely overwriting it (IPSO does that, doesn't it?)?  Are these
intentionally different in outcome?

In my opinion, factotum ought to detect ambiguous requests and have
rules for resolving them.

++L