| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Summary: Enhanced SLAPI task API and ported existing tasks to use new API.
|
| |
|
|
| |
Summary: Added new operation flag to skip writing modifiresname and related attributes. Updated password policy internal operations to use this new flag.
|
| |
|
|
| |
Summary: Handle poorly formatted DN's when normalizing. Also only check modify values against authenticated DN for DN syntax attributes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: rhds71 - search filters returns too many entries on integer attributes value greater than 2 to the power of 31
Reviewed by: nkinder, nhosoi (Thanks!)
Fix Description: The way >= and <= searches are supposed to work in LDAP is that you are supposed to define an ORDERING matching rule for the attribute you want to use in the search filter. The way our code is written, most strings "just work" as a side effect of the way bdb sorts the keys by default - so you can do (uid>=jvedder) and get what you would expect, even though LDAP says this is illegal because the schema definition of the uid attribute does not have an ORDERING matching rule. And INTEGER worked with the old binary format for the same reason. The only attribute definitions we use with ORDERING are attributes that use Generalized Time syntax (e.g. createTimestamp, et. al.) and numSubordinates (which uses INTEGER, but this is a special case handled internally by the db code).
The way it works now is that the indexing code will honor the ORDERING matching rule specified in the schema definition. Or, if ORDERING is not specified, the user can use the nsMatchingRule index configuration. This will allow an existing customer that depends all integer syntax attributes (e.g. uidNumber) to allow range searches by default to enable range searches without editing the schema. The syntax definition for the attribute must also specify a compare function. This compare function will be used by the bdb bt_compare() function.
I also fixed a bug in the integer normalize code - a string of all zeros should normalize to a single "0". In all other cases, the leading zeros should be removed.
Platforms tested: RHEL5 x86_64
Flag Day: Yes. Integer indexes will need to be rebuilt (except for numsubordinates).
Doc impact: Yes - document slapi API additions
QA impact: Pay close attention to tests that use >= or <= search filters, both with and without index attributes. Also, pay close attention to greater/less than searches using i18n collations.
New Tests integrated into TET: Forthcoming
|
| |
|
|
| |
Summary: Handle syncing multi-valued street attribute to AD.
|
| | |
|
| |
|
|
|
|
|
| |
Summary: [195305] make new_task() non-static
Changes: provide slapi_new_task and slapi_destroy_task as slapi APIs
Summary: [195307] task registration by plugins is wiped by task_init()
Changes: clean up old tasks before plugin_startall
|
| |
|
|
|
|
|
|
|
|
| |
Summary: configure needs to support --with-fhs (Comment #6)
Changes: Added the following include next to the end of the copyright block.
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
|
| |
|
|
|
| |
Summary: subtree search fails to find items under a db containing special characters (Comment#16)
Description: When dn contains rdn which includes '\\', it was escaped twice to generate a key for entrydn and caused mismatch in forming ancestorid index. It ends up the subtree search fail.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: ldapserver: Close potential security vulnerabilities in CGI code
Reviewed by: Nathan, Noriko, and Pete (Thanks!)
Fix Description: Clean up usage of sprintf, strcpy, fgets instead of
gets, fixed buffer usage, etc., mostly in the CGI code and other user
facing code (i.e. setup). Also, Steve Grubb told me about a GCC trick
to force it to check printf style varargs functions, to check the format
string against the argument string, for type mismatches, missing
arguments, and too many arguments.
In the CGI form argument parsing code, we needed to be more careful
about checking for bad input - good input is supposed to look like this:
name=value&name=value&.....
&name=value. I don't think the original code
was checking properly for something like name&name=value.
There was another place where we were not checking to see if a buffer
had enough room before appending a string to it.
I had to change a couple of functions to allow passing in the size of
the buffer.
Fixed some issues raised by Noriko and Nathan.
Platforms tested: RHEL4
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: recursion causes OOM with bad DN in dn2ancestor
Reviewed by: All (Thanks!)
Fix Description:
The fix looks scary, but I thought it would be best to get rid of
recursion entirely (ugh - recursion in a multi threaded server - this
isn't lisp . . .). Along with eliminating recursion, I created a new
function called slapi_dn_find_parent that just returns a pointer to the
beginning of the parent of the given dn, rather than returning a copy
(as in slapi_dn_parent), to eliminate malloc/free in cases where it is
unnecessary such as iterating through the parents in an DN. The new
function is basically just the guts of slapi_dn_parent with one twist,
specifically to address the bug in question - it skips through
consecutive runs of DN separator characters. We should probably have a
function like const char *slapi_dn_is_valid(const char *) that returns
NULL if the given DN is valid or returns a pointer to the first invalid
character if not. We could probably save a lot of time in processing
bad or malicious client requests.
Anyway, back to dn2ancestor. The given ancestordn must contain the
_unnormalized_ parent DN, since some clients get irritated when they get
back an DN in a different form than given. However, we need to have a
normalized DN to pass to dn2entry, and we cannot use a single Slapi_DN
that has both a dn and a ndn that are passed in byval (unless we add a
new API or skip the API altogether), so the variable ancestorndn holds
the normalized DN. Using the original pointer to the given sdn also
allows us to avoid malloc/free entirely.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: We need a test case that calls moddn and
modify operations with really bad DNs, consisting of nothing but
thousands of ',', '+', and '=' chars.
|
| | |
|
| | |
|
| |
|
|
| |
sync plus associated UI
|
| |
|
|
| |
warnings on Linux; remove pam_passthru from DS 7.1
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: The auth specific PAM libraries do not have a run time
dependency on libpam, but they do use symbols
in libpam - they expect the executable has already loaded libpam and
made its symbols visible to all other
dynamically loaded libraries. This breaks with DS when loading the PAM
plugin since we just use the default
dlopen arguments, which make the symbols private. We need a way to tell
the plugin loader to treat certain
plugins differently without changing the behavior for all plugins.
Reviewed by: dboreham, nkinder (Thanks!)
Fix Description: Added two new plugin configuration options:
nsslapd-pluginLoadNow and nsslapd-pluginLoadGlobal. These are boolean
valued and false by default (also false if absent). LoadNow causes all
symbols in the plugin and all of its dependents to be loaded
immediately, as opposed to load lazy which only loads the symbol when
used the first time (we probably don't ever want to do this, but it's
there if we need it). LoadGlobal makes all loaded symbols visible to
the executable and all other dynamically loaded libraries, which solves
the PAM problem.
Platforms tested: RHEL3
Flag Day: no
Doc impact: Yes. Need to document the two new plugin config attributes
and their behavior, and document slapi_entry_get_bool().
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
|
|
|
(foxworth)
|
