From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 8 Feb 2005 00:12:19 -0500 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] factotum & invalid entries In-Reply-To: <2872b3cbd27d48bc556bc9be60560d38@proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2872b3cbd27d48bc556bc9be60560d38@proxima.alt.za> Topicbox-Message-UUID: 41b2b700-eace-11e9-9e20-41e7f4b1d025 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