On 10/22/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > On Sat, Oct 20, 2007 at 04:38:04PM -0500, Trevor Highland wrote: > > This patch changes eCryptfs to use the session keyring rather than > > the user keyring. The path to the ecryptfsd is currently hardcoded. > > The path should be determined based on where ecryptfsd will be > > installed, but I was sure how to do that. > > Rather than doing an execve(), I would rather just put most of what is > in src/daemon/main.c into libecryptfs and have the child call that > instead. After all, we are still all one big happy family under > ecryptfs/src/.
Hello Michael, How do you cope with the scenario people use ecryptfs-manager more than once? This is a valid scenario... you have as many daemons as execution number. I am sorry I raising this again and again... But also for this one, if the daemon would have a socket to accept keys, it will be solved. ecryptfs-manager will call forward_keys_to_daemon via libecryptfs. This will check if the socket exists on filesystem, if not it will run a new daemon instance. It will read all keys from current session keyring (serialized) and write them into the socket. The daemon will read the serialized keys and put them into its own session keyring. This way you always have one daemon per user, allowing to move keys between a process and the daemon. It does not solve the storing of user passphrase in memory, but it is a direction forward. Best Regards, Alon Bar-Lev. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ eCryptfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
