Hello, This is nice! Solves the major issue. But results on many daemons running if user adds keys in several ecryptfs-manager instances.
I have another annoying question... :) Except for the passphrase keys which are used directly by the kernel module, why should the other keys modules use the key store anyway? I think that any key not known to the kernel can be forward (as default route) to the netlink socket for further processing. Also the default encryption key if not exists on store (none passphrase), it may be forwarded to the netlink socket. So I understand the use of key store for keys used directly by kernel, but I don't understand why it is enforced to keys used by the userspace. The issue of the passphrase keys can be easily be solved by setting the key contents as unreadable, and all other keys may be loaded to into the daemon user userspace interface such as pipe, right? Best Regards, Alon Bar-Lev. On 10/20/07, Trevor Highland <[EMAIL PROTECTED]> wrote: > Hi all, > > 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. > > Trevor > > ------------------------------------------------------------------------- > 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 > eCryptfs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel > > > ------------------------------------------------------------------------- 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 eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
