On Sat, Oct 13, 2007 at 11:09:16PM +0200, Alon Bar-Lev wrote: > I already have kde, gnome and ncurses dialogs.
Good to see this. > The main issue is that the netlink socket is somehow affected > from the fork(), the kernel believe that the user mode returned? > > Oct 13 21:50:13 alon1 decrypt_pki_encrypted_session_key: Failed to > receive tag 65 packet from the user space daemon 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... The eCryptfs kernel module requires that only one userspace daemon be in communication with the kernel for any given user id. The daemon must register itself with the kernel on launch, and all communications must be associated with the euid of the user and with the pid of the daemon that originally registered. If a forked child of the daemon needs to send a message to the kernel, it should do so via the original process with the pid that registered initially. This might require some IPC code in order to multiplex responses through the parent process, and we also need to carefully consider what happens in the kernel when multiple simultaneous requests go out with out-of-order responses for any given pid/euid combo. Request msg_ctx structs on a queue correlate with distinct syscall events, so I think it should work okay, but this has never been tested with a daemon that forks off processes that independently (and asynchronously) fire back responses to the kernel module via the parent. See fs/ecryptfs/messaging.c::ecryptfs_process_response(). 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
