On Sat, Oct 13, 2007 at 11:51:07PM +0200, Alon Bar-Lev wrote: > On 10/13/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > > There's a timeout on receiving the reply from the daemon; see > > fs/ecryptfs/messaging.c::ecryptfs_wait_for_response(). That needs to > > be tweaked if there is going to be an interactive prompt in the middle > > of a syscall. Aside from that... > > Oh... So this what happens... > How do you think it can be solved?
That timeout is a kernel parameter; see the module_param() set in sf/ecryptfs/main.c. > Also please notice that some crypto operations (smartcards) may take > long, I know cards that takes about 5 seconds for 2048 RSA > operation. We set the default to 3 seconds for now. It looks like, with this new smartcard feature, that should probably be increased to at least 10 (fs/ecryptfs/ecryptfs_kernel.h::ECRYPTFS_MAX_MSG_CTX_TTL). > > The eCryptfs kernel module requires that only one userspace daemon be > > in communication with the kernel for any given user id. The daemon > > Oh... I never meant to run another daemon in order to communicate with > kernel... Just fork(), exec(), wait for user entry and return it to > parent. > Only the parent communicate with netlink socket. So long as all kernel communications are coming from the parent, then there should be no problem. If you continue to see problems after the timeout is increased, then I will need to run the code with debug statements in the kernel to find out where the problem is. Thanks, Mike
signature.asc
Description: Digital signature
------------------------------------------------------------------------- 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
