--On September 17, 2006 2:48:43 PM -0400 Andrei Tchijov
<email@hidden> wrote:
Apple docs talking about "login" keychain and "default" keychain as two
separate entities. Apple mentions that "usually" "login" keychain is
"default" keychain, but obviously it does not have to be true all the
time (In "Keychain Access" you can apply "Make default keychain" action
to ANY(almost any) keychain). Now, there is no "un- make default"
action, but by creating new keychain, making it default and then
deleting it, it is possible to get to situation when there is not
"default" keychain. Now, the problem is what to do if your application
needs to save piece of secure information, but does not wont to create
new keychain. I used to rely on "SecKeychainCopyDefault" to get
"default" keychain and than use this keychain to store what ever I need
to store. It looks like it is far from been bulletproof ( there is even
special error code -25307 : "A default keychain does not exist". to
react on situation when there is no default keychain). So what else left
to do? There is no "SecKeychainCopyLogin" API and I think one can not
expect to find "login" keychain always in
~/Library/Keychains/login.keychain (The fact that login.keychain does
not have to be in ~/Library/Keychains made me switch to
"SecKeychainCopyDefault" in a first place ). Will passing "nil" in place
of keychain in APIs like
SecKeychainFindInternetPassword/SecKeychainItemCreateFromContent will
work in situation where there is NO default keychain?
The really short answer: If you get the -25307 error, you should probably
issue an error message and not store the secret. Read on for why.
First a few basic facts.
Both read and write API calls for keychains accept NULL as the "keychain"
(usually first) argument. For reading calls, the default is "search the
keychain search list". For write calls, the default is "write to the
default keychain." Both the search list and the default keychain are user
preferences (in ~/Library/Defaults/com.apple.security.plist).
The default keychain defaults (no pun intended) to the login keychain, but
can be changed to identify any keychain the user likes. The UI for this is
Keychain Access's "Make XXX the Default" menu item. The API call for this
is SecKeychainSetDefault.
There is *always* "a" default keychain. It's either identified in the
preference, or defaulted (to the login keychain) if there is no preference.
However, it is possible (as you noticed) for the default keychain to be
missing (because someone removed it, or it's offline, etc.) That's what the
-25307 error really means.
(The "login keychain", for completeness's sake, is
~/Library/Keychains/login.keychain" in modern systems, but it used to be
the short user name (without any extension) in older versions of the
system. Even Tiger still looks for the short name first, for compatibility.
There is no call to "set" the login keychain. Think of it as a system- and
user-dependent constant.)
Now some basic practical advice.
The security preferences (which includes the keychain search list and
default keychain) are *user preferences*. They belong to the user. They are
permanent and global. You do not want to mess with them without first
getting the user's clear and explicit consent. That means the user answered
a dialog saying "make it so". It doesn't mean you think the user is better
off if you fix things.
The situation where the default keychain has gone missing is not something
that you just want to fix or work around quietly. It means that the place
the user has chosen to (by default) store new secrets has disappeared. You
don't know the nature of this disappearance. It could have been user error.
It could have been that the default keychain is on a USB drive, and the
user knows exactly what he's doing when he pulls it out of its socket. It
could even be that it's a smart card or other weird device.
Now there are situations where you want to store a secret in a particular
place. Some programs have private keychains for that purpose. That's
legitimate (if not exactly encouraged). But if you have no specific
keychain in mind, then you really want to store to the default keychain.
And if that fails (because of -25307 or any other reason), you shouldn't
take that as encoragement to find some other keychain, somewhere, to store
your item into. You don't know what's going on. You should tell the user
about the problem and let him decide what to do.
Please understand that the place where you store secrets matters, security
wise. Storing user secrets in unexpected (to the user) places can make you
the conduit for odd security attacks on the user. It's much safer to fail
such an operation and let the user know that his environment has been
messed up. (Remember that the "fix" could be as simple as inserting the USB
dongle he's forgotten to plug in.)
And for the unofficial record, there is an SPI (internal API) function
(SecKeychainCopyLogin) to get the login keychain. That is not an invitation
to pick it willy-nilly to try to store things into it. If the user changed
the Default keychain, he expressed his intent that you should *not* store
things into the login keychain for some reason. You have no idea why that
is. Don't second-guess the user.
P.S. On a separate but related subject, I have a customer who some how
end-up in the "no default keychain" situation (My application gets
-25307 from SecKeychainCopyDefault and none of keychains shown in "bold"
in "Keychain Access"). However, when he is trying to apply "make
default keychain" to his login keychain, he can not. The menu item is
grayed out. So the question is: what could prevent "make default
keychain" action from been available and how to fix it ( "keychain first
aid" does not report any problems with his setup).
No idea. Switching to another keychain and then to the login keychain might
help. In extremis, throwing on the security preferences (and then logging
out and back in) will most likely fix the problem, whatever it might be.
Cheers
-- perry
---------------------------------------------------------------------------
Perry The Cynic email@hidden
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
---------------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/apple-cdsa/email@hidden
