[launchd-dev] Directory Access launching?

[Dave Zarzycki]

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