osx - Invisible files associated with OS X keychains -

osx - Invisible files associated with OS X keychains -

it seems keychain file (with extension .keychain) have invisible file associated it, located in same directory.

this invisible file has these properties:

it empty (zero bytes). its permissions 0444 (read-only users).

its name consists of .fl followed 8 hex characters. example:

.fl043d1edd .fl947e1bdb .fl9faf0136 .fl12663120 .fl8e6efc6c .flcf600f4b .fl1d8ece61 .fl0d1d1ba9 .fl79e88cd1 .fl62323d2f .fl75262c83 .fl652f188e

the invisible file can deleted, when keychain's contents next modified, invisible file recreated same name.

here steps demonstrate, using keychain access utility:

create new keychain, selecting file > new keychain , choosing directory in create it. invisible file created in same directory new keychain. delete invisible file (using finder or terminal). modify keychain's contents. example, add together secure note keychain, selecting file > new secure note item. invisible file recreated same name. delete keychain, selecting file > delete keychain > delete references & files. invisible file deleted too.

i've verified occurs in os x 10.8 , 10.9.

update

the same invisible files created when manipulating keychains using apple's security tool in terminal:

create new keychain. invisible file created.

$ cd ~/desktop/ $ ls -1a . .. $ /usr/bin/security create-keychain ~/desktop/test.keychain $ ls -1a . .. .fl1bce4b9a test.keychain

delete invisible file.

$ rm .fl1bce4b9a $ ls -1a . .. test.keychain

modify keychain's contents (eg: adding net password). invisible file recreated same name.

$ /usr/bin/security add-internet-password -a business relationship -s google.com -w password ~/desktop/test.keychain $ ls -1a . .. .fl1bce4b9a test.keychain

delete keychain. invisible file deleted too.

$ /usr/bin/security delete-keychain ~/desktop/test.keychain $ ls -1a . .. questions why these invisible files created? purpose? what fl mean in filename? what 8 hex characters in filename? kind of unique id or hash identifying keychain? is there way prevent these files beingness created when keychains created or modified?

after lot of investigating, i've managed reply of questions:

the invisible file implements write lock keychain's database. .fl filename prefix lock files created atomicfile class in security framework. the 8 hex characters in filename origin of sha-1 hash of keychain's filename. example, if keychain file called test.keychain, sha-1 hash of filename begins 1bce4b9a... , lock file called .fl1bce4b9a. i haven't discovered way prevent lock file beingness created when keychain created or modified. think it's impossible, i'd interested if can figure out way it.

here details of investigation:

keychain's locked/unlocked status

i noticed invisible file not affected keychain's locked/unlocked status. if invisible file has been deleted, locking/unlocking keychain not recreate invisible file.

system calls

i did investigating using file activity template in apple's instruments tool.

these scheme calls responsible manipulating invisible file:

creating invisible file when new keychain created: security::atomicfile::create(unsigned short) security::refpointer<security::atomiclockedfile>::release_internal() relevant part of phone call tree recreating invisible file when keychain's contents modified: security::atomicfile::write() security::refpointer<security::atomiclockedfile>::release_internal() relevant part of phone call tree deleting invisible file when keychain deleted: security::atomicfile::performdelete() relevant part of phone call tree c++ files

these relevant files , classes (source code available apple open source os x 10.9.2):

atomicfile.cpp security::atomicfile security::atomiclockedfile security::atomictempfile security::localfilelocker appledatabase.cpp security::appledatabase security::dbmodifier comments in source code

the comments in files provided clues:

atomicfile::atomicfile() "compute name of lock file file" atomicfile::create() "lock file writing , homecoming newly created atomictempfile." "now have created lock , new db file create tempfile object." localfilelocker::lock() "if lock file doesn't exist, create it" "try exclusive access file" "check , see if file have access still exists. if not, file shared our file lock due hash collision , has thrown our lock away -- that, or user blew lock file away himself." dbmodifier::modifydatabase() "now holding write lock" atomicfile::write() "lock database file writing , homecoming newly created atomictempfile." atomicfile::performdelete() "aquire write lock , remove file." "unlink our lock file" generation of lock file's name

i found code in atomicfile constructor:

class="lang-cpp prettyprint-override">char buffer[256]; sprintf(buffer, "%08x", hash); mlockfilepath = mdir + ".fl" + buffer;

where hash first 4 bytes of sha-1 hash of keychain's filename.

note: using 4 bytes (32 bits) of hash, there's reasonable chance of hash collision, mentioned in comment in localfilelocker::lock().

operation of lock

the flock() scheme phone call used manipulate lock on lock file.

here's phone call tree when keychain's database beingness locked writing:

class="lang-cpp prettyprint-override">dbmodifier::createdatabase() or ::modifydatabase() or ::deletedatabase() atomicfile::create() or ::write() or ::performdelete() atomiclockedfile::lock() localfilelocker::lock() flock(mlockfile, lock_ex) // exclusive lock

and when it's beingness unlocked after writing:

class="lang-cpp prettyprint-override">dbmodifier::commit() atomictempfile::commit() refpointer<atomiclockedfile>::setpointer(atomiclockedfile*) refpointer<atomiclockedfile>::release_internal() atomiclockedfile::~atomiclockedfile() // destructor atomiclockedfile::unlock() localfilelocker::unlock() flock(mlockfile, lock_un) // unlock

osx locking keychain flock security-framework