I am going to have to hold off on this patch for now; it brings up too many unresolved issues.
On Sat, Oct 20, 2007 at 04:38:04PM -0500, Trevor Highland wrote:
> +#define ECRYPTFSD_PATHNAME "/usr/bin/ecryptfsd"
> +
This path should be determined by configure.ac and supplied as a -D
parameter to gcc.
Better yet, we should just be forking and calling a daemon function
directly rather than making this shell-ish call:
> + execve(ECRYPTFSD_PATHNAME, cmd, env);
> - rc = (int)keyctl_search(KEY_SPEC_USER_KEYRING, "user", auth_tok_sig, 0);
> + rc = (int)keyctl_search(KEY_SPEC_SESSION_KEYRING, "user",
> auth_tok_sig, 0);
So this could be one of the following:
KEY_SPEC_THREAD_KEYRING
KEY_SPEC_PROCESS_KEYRING
KEY_SPEC_SESSION_KEYRING
KEY_SPEC_USER_KEYRING
KEY_SPEC_USER_SESSION_KEYRING
KEY_SPEC_GROUP_KEYRING
We have not really had a good discussion on which of these would
really be the best for storing the keys (at least for now; until we
get a better way of managing the keys). For instance, why pick
KEY_SPEC_SESSION_KEYRING rather than KEY_SPEC_USER_SESSION_KEYRING?
> + printf("\t%d. Start eCryptfs daemon\n", MME_ECRYPTFSD);
I like including this option, but let's first get our story straight
with how daemons interact when this options is selected multiple
times. For instance, I think they should write a .pid file under /var
and react appropriately if something is already there.
Thanks,
Mike
pgpaBM49qkmAC.pgp
Description: PGP 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
