Re: [9fans] factotum & invalid entries

Re: [9fans] factotum & invalid entries

[YAMANASHI Takeshi]

> > When the factotum is the one started by kernel on a cpu server,
> > adding a new key to the beginning of the list might change the
> > authdom which the cpu server running in?
>
> I was working on factotum and I realized that this question
> doesn't actually make sense.  The cpu server runs in as many
> authentication domains as there are p9sk1 server keys in its
> factotum.

Oookay,  a cpu server can run in multiple auth doms!
I thought a cpu could only run in a single auth dom...

Is this the same for other services which authenticate via
factotum 'proto=p9any' that they accepts multiple auth domain as well?
I guess the answer is yes...
--

Re: [9fans] factotum & invalid entries

[Russ Cox]

> Oookay,  a cpu server can run in multiple auth doms!
> I thought a cpu could only run in a single auth dom...
>
> Is this the same for other services which authenticate via
> factotum 'proto=p9any' that they accepts multiple auth domain as well?
> I guess the answer is yes...

Anything that uses proto=p9any (factotum, cpu, etc.)
kind of runs in multiple auth domains, though the names
are treated as a flat space by the kernel.
Other services, like apop or p9cr, don't have p9any's
flexibility and are tied to a specific domain -- the domain
on the first p9sk1 server key.

Russ

Re: [9fans] factotum & invalid entries

[YAMANASHI Takeshi]

> I changed things so that the new keys get inserted at the beginning
> of the list.  That should help a bit.

When the factotum is the one started by kernel on a cpu server,
adding a new key to the beginning of the list might change the
authdom which the cpu server running in?
--

Re: [9fans] factotum & invalid entries

[Russ Cox]

> > I changed things so that the new keys get inserted at the beginning
> > of the list.  That should help a bit.
>
> When the factotum is the one started by kernel on a cpu server,
> adding a new key to the beginning of the list might change the
> authdom which the cpu server running in?
> --

That's a bad thing.  I put in a different solution.
Keys with a disabled attribute are passed over when
looking for keys to use during authentication.  If
factotum figures out that the key you've entered is
bad, then it adds "disabled=by.factotum" to the
key before asking for a new one.  All keys append
to the end again.

Let's see what breaks this time.

Russ

Re: [9fans] factotum & invalid entries

[Tiit Lankots]

> Let's see what breaks this time.

It seems to me like the semantically correct solution. Thanks!

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> Let's see what breaks this time.

Would anything break if factotum actually "delkey"ed the failed entry?

++L

Re: [9fans] factotum & invalid entries

[arisawa]

> Would anything break if factotum actually "delkey"ed the failed entry?
>

Russ will answer but I would like to say.
I think nothing break but I want the key is kept untouched only adding
disabled flag
at the beginning.
because the disabled key is useful to see what was wrong.
And I want, the disabled key is replaced by new one when I add new key.
Then I can edit factotum without changing the order.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> I think nothing break but I want the key is kept untouched only adding
> disabled flag
> at the beginning.

Hm. You can't inspect the password at that point (sometimes I wish
there was a way to do that) so just the username is pertinent.
Wouldn't a log entry be more useful and less intrusive?

++L

Re: [9fans] factotum & invalid entries

[arisawa]

> Hm. You can't inspect the password at that point (sometimes I wish
> there was a way to do that) so just the username is pertinent.
> Wouldn't a log entry be more useful and less intrusive?
>

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.

Current factotum is inconvenient if the order is matter.
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.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> 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

Re: [9fans] factotum & invalid entries

[arisawa]

some miscommunication probably because of my sketchy explanation.

My image is
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password?
key proto=p9sk1 dom=aichi-u.ac.jp user=bootes !password?
disabled key proto=p9sk1 dom=inside.plan9.bell-labs.com user=arisawa
!password?
key proto=p9sk1 dom=grid.bell-labs.com user=arisawa !password?
term%

Factotum knows attribute value list is useless or not.
If the list is confirmed useless in authentication process,
I would like disabled is put at the beginning.
Next time I will fix the problem and put
key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
then I will get
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password?
key proto=p9sk1 dom=aichi-u.ac.jp user=bootes !password?
key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
key proto=p9sk1 dom=grid.bell-labs.com user=arisawa !password?
term%

If I put wrong user name, say alice instead of arisawa, then factotum
is not
authenticated. therefore we will get:
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password?
key proto=p9sk1 dom=aichi-u.ac.jp user=bootes !password?
key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
key proto=p9sk1 dom=grid.bell-labs.com user=arisawa !password?
disabled key proto=p9sk1 dom=outside.plan9.bell-labs.com user=alice
!password?
term%
Wrong user name does no harm

The current problem is in that factotum put every data even if the data
is confirmed
invalid.

The above is rough sketch. we should examine more.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> 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

Re: [9fans] factotum & invalid entries

[arisawa]

> 	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.

If factotum automatically changed
	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
	disabled key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio
!password?
when it know the list is useless, you can add
	key proto=p9sk1 dom=outside.plan9.bell-labs.com user= proxima
!password?
at the place of disabled entry. this is what you desire.
What is the problem?
If factotum have deleted erroneous record then factotum put next record
only at the end.  If order is matter this make a problem.

Kenji Arisawa

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> If factotum automatically changed
> 	key proto=p9sk1 dom=proxima.alt.za user=lucio !password?
> 	disabled key proto=p9sk1 dom=outside.plan9.bell-labs.com user=lucio
> !password?
> when it know the list is useless, you can add
> 	key proto=p9sk1 dom=outside.plan9.bell-labs.com user= proxima
> !password?
> at the place of disabled entry. this is what you desire.

It's not what I desire: I don't want erroneous records in the factotum
database and I fail to see why anyone else would.  It solves a
non-existent problem, as deleting the record has the same effect.

> What is the problem?

Ugliness?  Note that the record is the most recently added record, so
the sequence is not affected.

> If factotum have deleted erroneous record then factotum put next record
> only at the end.  If order is matter this make a problem.

But factotum always did that, and it's precisely what I would do
manually.  As I mentioned, the sequence is not altered, nor should it
really matter if it was altered.

++L

Re: [9fans] factotum & invalid entries

[Russ Cox]

In response to the flood of messages in this thread:

- I decided against silently deleting keys.  It would be very
  confusing if keys just magically disappeared.  I like the
  disabled=by.factotum tag a lot better.  I didn't use the log
  file mainly because it's intended only for debugging messages.
  I wouldn't think to look there to figure out why a key disappeared.

- Adding disabled=by.factotum only changes whether
  factotum uses the key in authentications.  It doesn't
  change whether you can see the password.  You never can.
  That's the whole point of factotum.  Except in proto=pass,
  which exists to break the rule.

- Factotum has a precise semantics for disambiguating key
  selection: use the first one.  That said, there is nothing stopping
  you from adding your own tags and then using the -k flag to
  mount to resolve the ambiguity some other way.  This has
  been there since day 1.

- If you've developed a habit of deleting bad keys to avoid the
  original problem that was reported, you can drop the habit.

- When you add a new key with the ctl file, here is what happens.
  If there is already a key in factotum with exactly the same set
  of public attr=val pairs, that key is replaced with the new one
  and stays at the same place in the list.  Otherwise, the new key
  is appended to the list.  When doing this comparison, the role=
  and disabled= attributes are ignored.  This means that if you have
  a key like:

    key proto=p9sk1 dom=foo user=bar !password? disabled=by.factotum

  and you write a new

    key proto=p9sk1 dom=foo user=bar !password=quux

  to the ctl file, then the first key is replaced by the second.  But
if the first
  had an attribute baz=1 that the second did not, or vice versa, then
  the new key would just be added to the list.

There's a lot of incorrect speculation flying around about what
factotum might or might not be doing.  When in doubt, try it.

Russ

Re: [9fans] factotum & invalid entries

[rog]

> - When you add a new key with the ctl file, here is what happens.
>   If there is already a key in factotum with exactly the same set
>   of public attr=val pairs, that key is replaced with the new one
>   and stays at the same place in the list. Otherwise, the new key
>   is appended to the list.

does that mean it's now not possible to add a new key to the beginning
of the list (the old default)?

Re: [9fans] factotum & invalid entries

[Russ Cox]

> > - When you add a new key with the ctl file, here is what happens.
> >   If there is already a key in factotum with exactly the same set
> >   of public attr=val pairs, that key is replaced with the new one
> >   and stays at the same place in the list. Otherwise, the new key
> >   is appended to the list.
>
> does that mean it's now not possible to add a new key to the beginning
> of the list (the old default)?

Yes, that functionality is gone.  No one ever seemed to need it,
and I don't know the right way to express it.  I left the machinery
that made it possible.  In general I think it's better not to use
ambiguous key patterns.

Russ

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> Yes, that functionality is gone.  No one ever seemed to need it,
> and I don't know the right way to express it.  I left the machinery
> that made it possible.  In general I think it's better not to use
> ambiguous key patterns.

echo 'key -a|b proto=...' > /mnt/factotum/ctl, analogously to "bind"?

For that matter, would ">" and ">>" possibly represent different
operations (ducks!)?

++L

Re: [9fans] factotum & invalid entries

[rog]

> For that matter, would ">" and ">>" possibly represent different
> operations (ducks!)?

according to the man page, they did before (or they would have if stat /mnt/factotum/ctl
yielded length>0) so you're not too out there...

Re: [9fans] factotum & invalid entries

[Devon H. O'Dell]

On Tue, 2005-02-08 at 18:55 +0200, Lucio De Re wrote:
> > Yes, that functionality is gone.  No one ever seemed to need it,
> > and I don't know the right way to express it.  I left the machinery
> > that made it possible.  In general I think it's better not to use
> > ambiguous key patterns.
>
> echo 'key -a|b proto=...' > /mnt/factotum/ctl, analogously to "bind"?
>
> For that matter, would ">" and ">>" possibly represent different
> operations (ducks!)?
>
> ++L

> means send output (stdout) to a file and overwrite its contents

>> means append output to a file

:)

--Devon

Re: [9fans] factotum & invalid entries

[Lucio De Re]

> > means send output (stdout) to a file and overwrite its contents
>
Not necessarily, as rog pointed out, factotum retained the contents.
Other servers do likewise.

> >> means append output to a file

I never noticed a difference with factotum, although rog suggests
there was.  Maybe I should convince myself, I'll check when I get
home.  Options are ugly, but if there is reason to be explicit, then
I can't think of a better approach.

++L

Re: [9fans] factotum & invalid entries

[rog]

> I never noticed a difference with factotum, although rog suggests
> there was.

not quite.

the man page used to say:

: If the offset of the write is zero, the key is added at the beginning
: of factotum's list; otherwise, it is added to the end.

this would have meant that there was a difference between '>' and '>>'
*if* the length of the ctl file had been greater than zero (all '>>'
does is set the offset to the length returned from stat).  this would
have been an easy fix, if anyone had cared.

Re: [9fans] factotum & invalid entries

[Russ Cox]

> > I changed things so that the new keys get inserted at the beginning
> > of the list.  That should help a bit.
>
> When the factotum is the one started by kernel on a cpu server,
> adding a new key to the beginning of the list might change the
> authdom which the cpu server running in?

I was working on factotum and I realized that this question
doesn't actually make sense.  The cpu server runs in as many
authentication domains as there are p9sk1 server keys in its
factotum.  It doesn't matter where you put the key -- beginning
or end of list.  In the p9any protocol, factotum will offer as possible
authentication domains all the proto=p9sk1 keys that
have no role attribute or an explicit role=server attribute.

It's not generally safe to be using the cpu server factotum as
your personal one, since adding new role-less p9sk1 keys
allows people in those domains to get in.  Probably the key
prompt should make sure to specify a role whenever it asks
for a key.

Russ

Re: [9fans] netpbm

[C H Forsyth]

>>Enhanced Unix "tar" utilities all seem to be able to do it.

i dare say it can.
cd /usr/src/contrib/tar; wc -l lib/*.c src/*.c
	... far too many files
   24449 total

and that's an old version. it has got `remote tape access',
though.  i'd forgotten about that. there's probably a command
language interpreter in there somewhere.

plan 9's pax is only 9000 lines, and is a little behind the times:
cd /usr/src/bin/pax; wc -l *.c
	...
    13455 total

does anyone still use cpio or pax?  apparently
it's like that OSI stuff that never quite dies,
however many stakes have been banged through its heart.

[9fans] factotum & invalid entries

[Tiit Lankots]

I don't have a secstore. Each time I connect to, say, sources, and I type
either an incorrect username or password, I can't connect (authentication
fails) until I clean factotum's database and get it correct the first time.

What exactly happens when authentication fails and factotum re-prompts
the user for credentials?

Re: [9fans] factotum & invalid entries

[Russ Cox]

> I don't have a secstore. Each time I connect to, say, sources, and I type
> either an incorrect username or password, I can't connect (authentication
> fails) until I clean factotum's database and get it correct the first time.

I think you are half-mistaken.  If you type a bad password, it should be
no big deal.  If you type a bad user name, that's when you get the
infinite loop.

> What exactly happens when authentication fails and factotum re-prompts
> the user for credentials?

If you type the same user name and a new password, then factotum
replaces the bad key, and all is well.  But if you type the wrong user name
the first time and then get it right the second time, factotum won't think
the two keys match (the user names are different!) so your key gets
added to the end of the list.  Factotum looks for keys to use from the
beginning of the list, so it finds the bad key again, and adding more
keys isn't going to help.

I changed things so that the new keys get inserted at the beginning
of the list.  That should help a bit.

Russ