On Mar 4, 2008, at 2:53 PM, Levi Brown wrote:
Hello all,
I have an interesting situation which I thought I might be able to utilize launchd to help me solve, but I could use some expert advice.
The idea is pretty simple:
I use gnupg. gnupg is used by services I use. gnupg stores all its information in ~/.gnupg unless the gnupg executable is called with a flag to tell it to do otherwise. Since I do not have control of how the executable is referenced by these services, the ~/.gnupg directory is my only choice. Stored inside the ~/.gnupg directory is the public and private keys for signing, en/decrypting, configuration, etc. which is sensitive information and could easily be accessed should my machine be stolen, for instance.
I'd like to store the contents of this directory on an encrypted disk image which is automatically attached and detached based on need. So, ideally, there would be a way to have a particular directory be monitored for access, and once accessed, a script could be called to mount the image. After a period of inactivity to this path, the volume could be detached.
automount and autofs are intended to do this kind of operation for network volumes an even provide a executable map facility which gives one a hook into the need to mount a directory based on access, however this is "old school" unix compared to the launchd train of thought, and I've not been able to get a solution working with this approach.
Is there some configuration key like PathState, or NetworkState which could be used to achieve this goal? Other suggestions?
Levi, If I am following your thought process correctly, I do not believe there is currently a mechanism with launchd that will let you accomplish your goal. I'm also not sure this is the problem domain of launchd. The primary design paradigm of launchd revolves around IPC (be it Unix sockets or Mach ports). Secondarily, launchd supports monitoring a few Unix subsystems for changes (path state and network state are good examples). Neither of these two goals involve interposing filesystem APi like autofs or automountd (like you gave as examples). You might want to try and find some contacts within Apple's filesystem engineering community to accomplish your goal. I suspect that the filesystem team will assert that the normal filesystem permission model is good enough. If you are not satisfied, then I suspect that they will assert that Apple's FileVault technology is appropriate. Good luck, davez