From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <650b439e355682372e7a55e68df66554@proxima.alt.za> References: <650b439e355682372e7a55e68df66554@proxima.alt.za> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: arisawa@ar.aichi-u.ac.jp Subject: Re: [9fans] factotum & invalid entries Date: Mon, 7 Feb 2005 15:47:52 +0900 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 40cfbd92-eace-11e9-9e20-41e7f4b1d025 > 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