I think I’m going to rewrite pwmd to work with a filesystem rather than an XML document. This would allow for better access control by using filesystem ACL’s and permissions and would be easier to use and less bug-prone. The idea is borrowed from the pass(1) shell script but that method uses gpg(1) for decryption of an encrypted file and doesn’t support passphrase caching as well as pwmd.
This would also allow for caching of a single file path rather than an entire XML document containing passphrases. It would also handle symbolic links (target attributes), NFS, SSHFS (fuse), among other things, better.
As an example, the libpwmd ‘pwmc’ client would basically be the same:
echo 'GET /some/file/path' | pwmc --cache-timeout 300 --rootdir ~/.store
echo 'GET /http:\/\/host.com/username | pwmc
Pwmc would connect to a (default) pwmd socket. Pwmd then determines whether the file path is cached or not. If not, calls gpg/2 to decrypt the file using gpg-agent for prompting of passphrase input if needed, then returns the decrypted data back to pwmc while optionally caching the data.
A better GUI client could be written to behave more like a file manager. A hidden file could replace what is an XML element attribute now.
The only real drawback I can tell is performance. Pwmd would use GPGME for encryption and decryption and that requires forking a new gpg/2 process for each file path. May not be too bad, though. We’ll see how it goes…
UPDATE (Sat Sep 6 12:26): I’m going to stick with the way it’s done now rather than using the filesystem. Caching multiple files (and even secret keys) is just too cumbersome. I will add per-element ACL support obtained via SO_PEERCRED or a TLS fingerprint hash, though. I may also add OpenPGP support but that will be a major version bump would remove the native pwmd file format.
bjk's blog 