| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Bug Description: WinSync ignores entry if NT attributes are added later.
Reviewed by: nkinder (Thanks!)
Fix Description: If we are replaying a modify operation, we need to check if the ntUser objectclass is being added along with the other attributes that tell the sync service to sync this entry. If the objectclass is being added or replaced, we check the existing entry to see if it is still a sync-able entry. If it is, we call process_replay_add to add the entry. I changed this function to accept a Slapi_Entry to add rather than the operation structure. Finally, I had to change the way we send the Account Control flags to take into account an entry that may have been added as a result of a modify operation.
I fixed a memory leak when setting the Slapi_Attr attribute type, and cleaned up a compiler warning.
NOTE: There will be no clear text password to send (unless the userPassword was modified in the same modify operation). This means the account will be added to Windows, and will be enabled, but will be essentially unusable - the user cannot login - until either the user modifies the password on the directory server side, or the administrator resets the password.
Platforms tested: RHEL5
Flag Day: no
Doc impact: yes - we will have to document the new winsync behavior
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: DN with antislash('\') rename (modrdn) problem
Problem description:
Unescape codes in the DS (strcpy_special_undo in ava.c and
strcpy_unescape_dnvalue in dn.c) were "unescaping" more than the escape code
(e.g., escape_dn_value in NET LDAP) does escaping. The test string
'BeforeSlash\AfterSlash' fortunately/unfortunately contains '\Af', which is
considered '\##' (where # is hex number) by the DS unescape functions even
though it was not meant to be escaped. As long as using UTF-8, there is no
chance for the server to receive "\af".
Change description:
1) There were identical static functions: strcpy_special_undo (ava.c) and
strcpy_special_undo (dn.c). Merged them to strcpy_unescape_value and put it in
util.c.
2) In the unescape/normalize functions for dn (strcpy_unescape_value in util.c
and substr_dn_normalize in dn.c), added a check for the first hex number in
'\##'. If the 8th bit is on, we don't do unescaping but store it as is since
the unescaped character is not UTF-8.
3) If 2 consecutive '\'s are passed to the unescape/normalize functions, keep
one of them.
|
| |
|
|
|
| |
Summary: Memory usage research: checking in the experimental code
See also: http://directory.fedoraproject.org/wiki/Memory_Usage_Research
|
| |
|
|
|
|
|
| |
Summary: rhds71 Invalid LDIF Syntax crashes directory server (comment #18)
Description: The problem was if an RDN ends with '\\', strcpy_special_undo
did not check if there is no more character, and incremented the pointer
beyond the end and accessed the address.
|
| |
|
|
|
|
|
|
|
|
| |
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
+
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Description: memory leaks using ber_scanf when handling bad BER packets
Reviewed by: All (Thanks!)
Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123783
Branch: HEAD
Fix Description:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179135#c0
I basically did a search through our code for all calls to ber_scanf,
ber_get_stringa, and ber_get_stringal and made sure we properly free any
arguments that may have been allocated. There was a bug in the ldapsdk
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179135 that causes
us to free uninitialized memory when trying to clean up the result of
ber_get_stringal (or ber_scanf with 'V'). I had to initialize some
variables to NULL so that we could properly clean them up, and added
some additional clean ups that were missing. Also, in repl_extop.c, we
were calling free on an array that we should have been calling
ch_array_free on. Yet another lesson in the evils of slapi_ch_free and
disabling compiler type checks in general.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no
|
| | |
|
| | |
|
| | |
|
|
|
(foxworth)
|
