On Tue, Oct 09, 2007 at 03:39:03AM +0200, Alon Bar-Lev wrote: > On Friday 05 October 2007, Alon Bar-Lev wrote: > CONFIGURATION > > Configuration is stored at ~/.ecryptfsrc.pkcs11. > > Attributes: > pkcs11-log-level (Integer, decimal) > Log level of pkcs11-helper, can be from 0-5. > > pkcs11-pin-cache-timeout (Integer, decimal) > Maximum PIN/session cache period in seconds. > -1 is infinite, until provider invalidates > session.
Internally, eCryptfs will parse that into a simple list of name-value
pairs. So you might want:
---
pkcs11-pin-cache-timeout=3
pkcs11-provider-name=bob
pkcs11-provider-allow-protected-auth=true
---
In ~/.ecryptfsrc; then, the decision graph nodes with names
"pkcs11-pin-cache-timeout", "pkcs11-provider-name", and
"pkcs11-provider-allow-protected-auth" will automatically get the
corresponding values from the rc file. Or, if they are specified on
the command line, then the decision graph code will grab it from
there. If it is a required value and it is supplied by neither the rc
file or the command line, then the user should be prompted for the
value.
That is the basic idea.
The decision graph code, at each node, simply checks the name-value
pair list for a name match. If a name matches, the decision graph code
just plugs in the value from that name-value node into the decision
graph node.
There could be a lot more intelligence to the parse/decision graph
code (e.g., there could be some notion of hierarchy), but it works
well enough for everything we have had to do up to this point.
To see what the name-value list looks like once all the parsing is
done, apply this patch and check your syslog.
If all you need is to get a simple set of values, and if you don't
really need any intelligence behind what happens as you read those
values, then you can avoid having to build your own decision graph
altogether and just generate a key_mod_param array instead, like what
the tspi key module does.
All this is ultimately meant to make it possible for parameters to
come from anywhere (rc file, command line, gui, interactive prompt,
etc.) and have key modules be able to get and use them seamlessly. And
I don't claim that our current solution is necessarily the best
possible one.
---
diff --git a/src/libecryptfs/module_mgr.c b/src/libecryptfs/module_mgr.c
index 0ba36d0..2c644c0 100644
--- a/src/libecryptfs/module_mgr.c
+++ b/src/libecryptfs/module_mgr.c
@@ -509,6 +509,15 @@ int ecryptfs_process_decision_graph(struct ecryptfs_ctx
*ctx,
rc = ecryptfs_parse_options(opts_str, &nvp_head);
ecryptfs_nvp_list_union(&rc_file_nvp_head, &nvp_head,
&allowed_duplicates);
+ {
+ struct ecryptfs_name_val_pair *cursor = rc_file_nvp_head.next;
+
+ while (cursor) {
+ syslog(LOG_INFO, "[%s] -> [%s]\n", cursor->name,
+ cursor->value);
+ cursor = cursor->next;
+ }
+ }
if (ecryptfs_verbosity) {
struct ecryptfs_name_val_pair *nvp_item = rc_file_nvp_head.next;
pgpDzh86yOmvC.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 eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
