Projects/Pluggable configuration - Revision history

Ghudson at 21:54, 12 October 2011

2011-10-12T21:54:38Z

2011-07-20T20:42:41Z

2011-07-20T19:02:54Z

2011-07-20T18:35:06Z

‎Using dynamic profile modules

2011-07-20T17:35:09Z

‎Using dynamic profile modules

2011-07-20T17:25:25Z

‎Using dynamic profile modules

2011-07-20T15:53:16Z

‎Dynamic profile modules

2011-07-20T15:52:54Z

‎Requirements and scope

2011-07-15T14:00:58Z

‎vtable profiles

2011-07-15T13:59:42Z

‎Using dynamic profile modules

← Older revision		Revision as of 21:54, 12 October 2011
Line 148:		Line 148:

	http://mailman.mit.edu/pipermail/krbdev/2011-June/010142.html		http://mailman.mit.edu/pipermail/krbdev/2011-June/010142.html
		+
		+	==Release notes==
		+
		+	Administrator experience:
		+
		+	* Add plugin interface for configuration.

← Older revision		Revision as of 19:02, 20 July 2011
Line 141:		Line 141:

	The new function will be used by libkrb5 to initialize profiles. Other profile API consumers will not load profile modules unless they specify the appropriate flag, since they may have security reasons to treat profile files purely as data rather than code.		The new function will be used by libkrb5 to initialize profiles. Other profile API consumers will not load profile modules unless they specify the appropriate flag, since they may have security reasons to treat profile files purely as data rather than code.
		+
		+	==Testing==
		+
		+	Automated C-language test programs will be added for vtable profiles and for loadable profile modules. A simple test module will be added in a subdirectory of util/profile to make the loadable profile test possible.

	==Relevant mailing list discussions==		==Relevant mailing list discussions==

@@ Line 139: / Line 139: @@
  profile_init_flags(const_profile_filespec_t *files, int flags,
                     profile_t *ret_profile);
 ==Relevant mailing list discussions==

@@ Line 135: / Line 135: @@
  #define PROFILE_INIT_ALLOW_MODULE       0x0001
  long
  profile_init_flags(const_profile_filespec_t *files, int flags,

← Older revision		Revision as of 17:25, 20 July 2011
Line 131:		Line 131:

	''modpath'' may be relative to the library directory of the krb5 build. When parsing the profile files for the first time, if a module directive is encountered before any other content, libprofile will halt parsing, load the specified module, and invoke the module's profile_module_init function to create a vtable and callback data pointer. The library handle for the module will be released when all copies of the resulting profile are released.		''modpath'' may be relative to the library directory of the krb5 build. When parsing the profile files for the first time, if a module directive is encountered before any other content, libprofile will halt parsing, load the specified module, and invoke the module's profile_module_init function to create a vtable and callback data pointer. The library handle for the module will be released when all copies of the resulting profile are released.
		+
		+	In the profile API, a new initialization function is added to allow the use of modules when loading a profile:
		+
		+	#define PROFILE_INIT_ALLOW_MODULE 0x0001
		+
		+	long
		+	profile_init_flags(const_profile_filespec_t *files, int flags,
		+	profile_t *ret_profile);

	==Relevant mailing list discussions==		==Relevant mailing list discussions==

@@ Line 119: / Line 119: @@
  long
- profile_module_init(int min_ver, const char *residual,
+ profile_module_init(const char *residual, struct profile_vtable *vtable,
-                     struct profile_vtable *vtable, void **cb_ret);
+                     void **cb_ret);
 This signature differs from the usual krb5 loadable module conventions in several ways, because profile modules are tailored to libprofile instead of libkrb5.  Because there is no separate cleanup function, a loadable module must implement the copy and cleanup methods unless it has no need for an allocated callback data pointer.

@@ Line 7: / Line 7: @@
 # An application can, when creating a krb5 context, specify a programmatic source of configuration for that context.
-# The system can cause krb5 configuration to come from a programmatic source (a dynamically loaded library) for all processes or for a subset of processes.
+# The system can cause krb5 configuration to come from a dynamically loaded library for all processes or for a subset of processes.
 Currently, GSSAPI applications cannot specify or directly access the krb5 context used by the GSSAPI library.  This problem is out of scope, but must be resolved (through a separate project) before application-level configuration control will be very useful.

@@ Line 77: / Line 77: @@
  struct profile_vtable {
      int min_ver;
      profile_get_values_fn get_values;
      profile_free_values_fn free_values;
      profile_cleanup_fn cleanup;
      profile_copy_fn copy;
      profile_iterator_create_fn iterator_create;
      profile_iterator_fn iterator;
      profile_iterator_free_fn iterator_free;
      profile_free_string_fn free_string;
      profile_writable_fn writable;
      profile_modified_fn modified;

@@ Line 130: / Line 130: @@
   module ''modpath'':''residual''
-''modpath'' may be relative to the library directory of the krb5 build.  When parsing the profile files, if a module directive is encountered before any other content, libprofile will halt parsing, load the specified module, and invoke the module's profile_module_init function to create a vtable and callback data pointer.  The library handle for the module will be released when all copies of the resulting profile are released.
+''modpath'' may be relative to the library directory of the krb5 build.  When parsing the profile files for the first time, if a module directive is encountered before any other content, libprofile will halt parsing, load the specified module, and invoke the module's profile_module_init function to create a vtable and callback data pointer.  The library handle for the module will be released when all copies of the resulting profile are released.
 ==Relevant mailing list discussions==