Este contenido no está disponible en el idioma seleccionado.
Chapter 7. Updated Packages
7.1. 389-ds-base Copiar enlaceEnlace copiado en el portapapeles!
Copiar enlaceEnlace copiado en el portapapeles!
7.1.1. RHSA-2013:0503 — Moderate: 389-ds-base security bug fix and enhancement update Copiar enlaceEnlace copiado en el portapapeles!
Copiar enlaceEnlace copiado en el portapapeles!
Updated 389-ds-base packages that fix one security issue, a number of bugs, and add various enhancements are now available for Red Hat Enterprise Linux 6.
The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which give detailed severity ratings, are available for each vulnerability from the CVE link(s) associated with each description below.
The 389-ds-base packages provide 389 Directory Server, which is an LDAPv3 compliant server. The base packages include the
Lightweight Directory Access Protocol (LDAP) server and command-line utilities for server administration.
Note
The 389-ds-base packages have been upgraded to upstream version 1.2.11, which provides a number of bug fixes and enhancements over the previous version. (BZ#800051)
Security Fixes
- CVE-2012-4450
- A flaw was found in the way 389 Directory Server enforced ACLs after performing an LDAP modify relative distinguished name (modrdn) operation. After modrdn was used to move part of a tree, the ACLs defined on the moved (Distinguished Name) were not properly enforced until the server was restarted. This could allow LDAP users to access information that should be restricted by the defined ACLs.
This issue was discovered by Noriko Hosoi of Red Hat.
Bug Fixes
- BZ#742054
- Previously, 389 Directory Server did not support the Simple Authentication and Security Layer (SASL) PLAIN mechanism. This mechanism has been added to the list of supported SASL mechanisms.
- BZ#742381
- Due to certain changes under the
cn=configsuffix, when an attribute value was deleted and then added back in the same modify operation,error 53was returned. Consequently, the configuration could not be reset. This update allows delete operations to succeed if the attribute is added back in the same modify operation and reset the configuration file as expected. - BZ#757836
- Previously, the
logconv.plscript used a connection number equal to 0 (conn=0) as a restart point, which caused the script to return incorrect restart statistics. The underlying source code has been modified and 389 Directory Server is now configured to use connection number equal to 1 (conn=1) as the restart point. - BZ#803873
- The
Windows Syncfeature uses the name in a search filter to perform an internal search to find an entry. Parentheses, “(” and “)” are special characters in theLDAPprotocol and therefore must be escaped. However, an attempt to synchronize an entry containing parentheses in the name from an Active Directory (AD) server failed with an error. With this update, 389 Directory Server properly escapes the parentheses and synchronization now proceeds correctly as expected. - BZ#818762
- When having an entry in a directory server (DS) with the same user name, group name, or both as an entry in AD and simultaneously the entry in AD was out of scope of the
Windows Syncfeature, the DS entry was deleted. This update adds the newwinSyncMoveActionDS attribute for the Windows Sync agreement entry, which allows the user to specify the behavior of out-of-scope AD entries. The value could be set to:By default, the value is set tonone, which means that an out-of-scope AD entry does nothing to the corresponding DS entry;delete, which means that an out-of-scope AD entry deletes the corresponding DS entry;unsync, which means that an out-of-scope AD entry is unsynchronized with the corresponding DS entry and changes made to either entry are not synchronized.
none, which fixes this bug. - BZ#830334
- Due to an incorrect interpretation of an error code, a directory server considered an invalid chaining configuration setting as the
disk fullerror and shut down unexpectedly. This bug has been fixed by using the correct error code and a directory server now no longer terminates due to an invalid chaining of a configuration setting. - BZ#830335
- Previously, restoring an
ldiffile from a replica, which had older changes that other servers did not see yet, could lead to these updates not being replicated to other replicas. With this update, 389 Directory Server checks the Change Sequence Numbers (CSNs) and allows the older updates to be replicated. As a result, all replicas remain synchronized. - BZ#830336
- When a directory server was under a heavy read and write load, and an update request was processed, the following error message or other similar
DB_LOCK_DEADLOCKerror messages appeared in the error log:These errors are common under these circumstances and there is no need to report them in the error log. With this update,entryrdn-index - _entryrdn_put_data: Adding the parent link (XXX) failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)
entryrdn-index - _entryrdn_put_data: Adding the parent link (XXX) failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 389 Directory Serverensures that these errors are handled properly and no longer logs these messages in the error log. - BZ#830337
- When a directory server was configured to use multi-master replication and the
Entry USNplug-in, the delete operation was not replicated to the other masters. This update modifies theEntry USNplug-in to prevent it from changing the delete operation into a delete tombstone operation, and from removing the operation before it logs into the change log to replay to other servers. As a result, the delete operation is replicated to all servers as expected. - BZ#830338
- Previously, 389 Directory Server did not refresh its Kerberos cache. Consequently, if a new Kerberos ticket was issued for a host that had already authenticated against a directory server, it would be rejected by this server until it was restarted. With this update, the Kerberos cache is flushed after an authentication failure and 389 Directory Server works as expected in the described scenario.
- BZ#830343
- Using the
Managed Entryplug-in in conjunction with other plug-ins, such asDistributed Numeric Assignment(DNA),Member of, andAuto Member, led to problems with delete operations on entries that managed theManaged Entryplug-in. Themanagerentry was deleted, but themanagedentry was not. The deadlock retry handling has been improved so that both entries are deleted during the same database operation. - BZ#830344
- Previously, replication errors logged in the error log could contain incorrect information. With this update, the replication errors have been modified to be more useful in diagnosing and fixing problems.
- BZ#830346
- When audit logging in a directory server was enabled, LDAP ADD operations were ignored and were not logged. This update removes a regression in the audit log code that caused the ADD operation to be ignored, and LDAP ADD operations are now logged to the audit log as expected.
- BZ#830348
- 389 Directory Server with a large number of replication agreements took a considerable amount of time to shut down due to a long sleep interval coded in the replication stop code. This sleep interval has been reduced to speed up the system termination.
- BZ#830349
- Previously, in a SASL map definition, using a compound search filter that included the “&” character failed because the “&” character was escaped. The underlying source code has been modified and searching with a filter that includes the “&” character works as expected.
- BZ#830353
- When 389 Directory Server used the
Managed Entryplug-in or theDNAplug-in, thevalgrindtool reported memory errors and leaks. With this update, a patch has been applied to prevent these problems, and memory is now used and deleted correctly. - BZ#832560
- When replication was configured and a conflict occurred, under certain circumstances, an error check did not reveal this conflict, because a
to-be-deletedattribute was already deleted by another master. Consequently, the conflict terminated the server. This update improves error checks to prevent replication conflicts from crashing the server. - BZ#833202
- Previously, internal entries that were in the cache were freed when retrying failed transactions due to a deadlock. This behavior caused problems in a directory server and this server could terminate under a heavy update load. With this update, the cached internal entries are no longer freed and directory servers do not crash in the described scenario.
- BZ#833218
- Due to improper deadlock handling, the database reported an error instead of retrying the transaction. Consequently, under a heavy load, the directory server got deadlock errors when attempting to write to the database. The deadlock handling has been fixed and 389 Directory Server works as expected in such a case.
- BZ#834047
- Internal access control prohibited deleting newly added or modified passwords. This update allows the user to delete any password if they have the modify rights.
- BZ#834054
- Certain operations, other than
LDAP Modifyoperations, can cause the 389 Directory Server to modify internal attributes. For example, aBINDoperation can cause updates to password failure counters. In these cases, 389 Directory Server was updating attributes that could only be updated during an explicitLDAP Modifyoperation, such as themodifyTimestampattribute. This update adds a new internal flag to skip the update of these attributes on other thanModifyoperations. - BZ#834056
- Due to an invalid configuration setup in the
Auto Memmberplug-in, the directory server became unresponsive under certain circumstances. With this update, the configuration file is validated, invalid configurations are not allowed, and the server no longer hangs. - BZ#834057
- When using SNMP monitoring, 389 Directory Server terminated at startup due to multiple
ldapservers listed in theldap-agent.conffile. With this update, the buffer betweenldapservers no longer resets and 389 Directory Server starts up regardless of the number ofldapservers listed in the configuration file. - BZ#834064
- Previously, the
dnaNextValuecounter was incremented in the pre-operation stage. Consequently, if the operation failed, the counter was still incremented. This bug has been fixed and thednaNextValuecounter is not incremented if the operation fails. - BZ#834065
- When a replication agreement was added without the LDAP BIND credentials, the replication process failed with a number of errors. With this update, 389 Directory Server validates the replication configuration and ensures that all needed credentials are supplied. As a result, 389 Directory Server rejects invalid replication configuration before attempting to replicate with invalid credentials.
- BZ#834075
- Previously, the
logconv.plscript did not grab the correct search base, and as a consequence, the searching statistics were invalid. A new hash has been created to store connections and operation numbers from search operations. As a result,logconv.plnow grabs the correct search base and no longer produces incorrect statistics. - BZ#838706
- When using the
Referential Integrityplug-in, renaming a user DN did not rename the user's DN in the user's groups, unless that case matched exactly. With this update, case-insensitive comparisons or DN normalizations are performed, so that the member attributes are updated when the user is renamed. - BZ#840153
- Previously, the
Attribute Uniquenessplug-in did comparisons of un-normalized values. Consequently, using this plug-in and performing theLDAP RENAMEoperation on an entry containing one of the attributes which were tested for uniqueness by this plug-in caused theLDAP RENAMEoperation to fail with the following error:With this update,Constraint Violation - Another entry with the same attribute value already exists.
Constraint Violation - Another entry with the same attribute value already exists.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Attribute Uniquenessensures that comparisons are performed between values which were normalized the same way, andLDAP RENAMEworks as expected in this situation. - BZ#841600
- When the
Referential Integrityplug-in was used with a delay time greater than 0, and theLDAP RENAMEoperation was performed on auserentry with DN specified by one or moregroupentries under the scope of theReferential Integrityplug-in, the user entry DN in thegroupentries did not change. The underlying source code has been modified andLDAP RENAMEoperations work as expected in the described scenario. - BZ#842437
- Previously, the
DNAplug-in could leak memory in certain cases for certainMODIFYoperations. This update applies a patch to fix this bug and the modifications are freed as expected with no memory leaks. - BZ#842438
- To improve the performance, the entry cache size is supposed to be larger then the primary database size if possible. Previously, 389 Directory Server did not alert the user that the size of the entry cache was too small. Consequently, the user could not notice that the size of the entry cache was too small and that they should enlarge it. With this update, the configured entry cache size and the primary database size are examined, and if the entry cache is too small, a warning is logged in the error log.
- BZ#842440
- Previously, the
Memberofplug-in code executed redundant DN normalizations and therefore slowed down the system. The underlying source code has been modified to eliminate redundant DN normalizations. - BZ#842441
- Previously, the directory server could disallow changes that were made to the
nsds5ReplicaStripAttrsattribute using theldapmodifyoperation. Consequently, the attribute could only be set manually in thedse.ldiffile when the server was shut down. With this update, the user is now able to set thensds5ReplicaStripAttrsattribute using theldapmodifyoperation. - BZ#850683
- Previously, 389 Directory Server did not check attribute values for the
nsds5ReplicaEnabledfeature which caused this feature to be disabled. With this update, 389 Directory Server checks if the attribute value fornsds5ReplicaEnabledis valid and reports an error if it is not. - BZ#852088
- When multi-master replication or database chaining was used with the
TLS/SSLprotocol, a server using client certificate-based authentication was unable to connect and connection errors appeared in the error log. With this update, the internal TLS/SSL and certificate setup is performed correctly and communication between servers works as expected. - BZ#852202
- Previously, there was a race condition in the replication code. When two or more suppliers were attempting to update a heavily loaded consumer at the same time, the consumer could, under certain circumstances, switch to total update mode, erase the database, and abort replication with an error. The underlying source code has been modified to prevent the race condition. As a result, the connection is now protected against access from multiple threads and multiple suppliers.
- BZ#852839
- Due to the use of an uninitialized variable, a heavily loaded server processing multiple simultaneous delete operations could terminate unexpectedly under certain circumstances. This update provides a patch that initializes the variable properly and the directory server no longer crashes under these circumstances.
- BZ#855438
- Due to an incorrect attempt to send the
cleanallruvtask to the Windows WinSync replication agreements, the task became unresponsive. With this update, the WinSync replication agreements are ignored and thecleanallruvtask no longer hangs in the described scenario. - BZ#856657
- Previously, the
dirsrvinit script always returned 0, even when one or all the defined instances failed to start. This update applies a patch that improves the underlying source code anddirsrvno longer returns 0 if any of the defined instances failed. - BZ#858580
- The schema reload task reloads schema files in the schema directory. Simultaneously,
Directory serverhas several internal schemas which are not stored in the schema directory. These schemas were lost after the schema reload task was executed. Consequently, adding aposixAccountclass failed. With this update, the internal schemas are stashed in a hash table and reloaded with external schemas. As result, adding aposixAccountis successful. - BZ#863576
- When abandoning a Simple Paged Result request, 389 Directory Server tried to acquire a connection lock twice, and because the connection lock is not self reentrant, 389 Directory Server was waiting for the lock forever and stopped the server. This update provides a patch that eliminates the second lock and 389 Directory Server works as expected in the described scenario.
- BZ#864594
- Previously, Anonymous Resource Limits applied to the
Directory Manager. However, the Directory Manager should never have any limits. With this update, Anonymous Resource Limits no longer apply to Directory Manager. - BZ#868841
- Even if an entry in AD did not contain all the required attributes for the POSIX account entry, the entry was synchronized to the DS as a POSIX entry. Consequently, the synchronization failed due to a “missing attribute” error. With this update, if an entry does not have all the required attributes, the POSIX account related attributes are dropped and the entry is synchronized as an ordinary entry. As a result, the synchronization is successful.
- BZ#868853
- When enabling replication level logging, the
Windows Syncfeature prints out what version of Windows or AD it detects. Previously, if the feature detected Windows Server 2003 or later, it printed out the following message:This message could be confusing for users who had a later version of Windows, such as Windows Server 2008. This update modifies the message and now the following message is printed out:detected win2k3 peer
detected win2k3 peerCopy to Clipboard Copied! Toggle word wrap Toggle overflow detected win2k3 or later peer
detected win2k3 or later peerCopy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#870158
- When a directory server was under a heavy load, deleting entries using the
Entry USNfeature caused tombstone entry indexes to be processed incorrectly. Consequently, the server could become unresponsive. This update fixes 389 Directory Server to process tombstone indexes correctly, so that the server no longer hangs in this situation. - BZ#870162
- Previously, the abandon request checked if the operation to abandon existed. When a search operation was already finished and an operation object had been released, a Simple Page Results request could fail due to this check. This update modifies 389 Directory Server to skip operation existence checking, so that Simple Paged Results requests are always successfully aborted.
- BZ#875862
- Previously, the
DNAplug-in attempted to dereference a NULL pointer value for thednaMagicRegenattribute. Consequently, ifDNAwas enabled with nodnamagicregenvalue specified in its configuration and an entry with an attribute that triggered the DNA value generation was added, the server could terminate unexpectedly. This update improves the 389 Directory Server to check for an emptydnamagicregenvalue before it attempts to dereference this value. As a result, 389 Directory Server no longer crashes if nodnamagicregenattribute is specified. - BZ#876694
- Previously, the code to check if a new superior entry existed, returned the “No such object” error only when the operation was requested by the directory manager. Consequently, if an ordinary non-root user attempted to use the
modrdnoperation to move an entry to a non-existing parent, the server terminated unexpectedly. This update provides a patch that removes the operator condition so that the check returns the “No such object” error even if the requester is an ordinary user, and themodrdnoperation performed to the non-existing parent successfully fails for any user. - BZ#876727
- aIf a filter contained a range search, the search retrieved one ID per one
idl_fetchattribute and merged it to the ID list using theidl_union()function. This process is slow, especially when the range search result size is large. With this update, 389 Directory Server switches toALLIDmode by using thensslapd-rangelookthroughlimitswitch instead of creating a complete ID list. As a result, the range search takes less time. - BZ#889083
- Previously, if an entry was added or created without plug-in interference, the
nsslapd-plugin-track-binddnfeature filled the value of theinternalModifiersnameandinternalCreatorsnameattributes with the original bind DN instead of the name of the actual plug-in that modified or added the entry. This behavior is undesired; thus thensslapd-plugin-track-binddnhas been modified to always show the name of the actual plug-in that performed these operations. - BZ#891930
- In previous versions of the 389-ds-base packages, an attempt to add a new entry to the
DNAplug-in when the range of values was depleted caused the following error message to be returned:This message was missing all additional information in recent versions of the 389-ds-base packages. With this update, a patch is applied to provide the returned error message with additional information.ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.
ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - BZ#896256
- Previously, an upgrade of the 389-ds-base packages affected configuration files. Consequently, custom configuration files were reverted to by default. This update provides a patch to ensure that custom changes in configuration files are preserved during the upgrade process.
Enhancements
- BZ#746642
- This update allows the
PAM Pass-throughplug-in to pass through the authentication process to different PAM stacks, based on domain membership or some property of the user entry, or both. Users now can login to Red Hat Directory Server using the credentials and account data from the correct AD server. - BZ#768084
- This enhancement improves the
automemberplug-in to check existing entries and writes out the changes which occur if these entries are added. - BZ#782975
- Previously, certain BINDs could cause only entries with the
modifiersnameormodifystimestampattribute to be updated. This behavior led to unnecessary replication traffic. This enhancement introduces the newreplicationfeature to decrease replication traffic caused by BINDs. - BZ#830331
- This enhancement adds the new
Disk Monitoringplug-in. When disk partitions fill up,Disk Monitoringreturns a warning. - BZ#830340
- Previously, two tasks were needed to be performed to clean an entire replication environment, the clean task and the release task. With this update, these tasks are incorporated in the
Cleanallruvfeature. - BZ#830347
- Previously, the
Paged Resultssearch was allowed to perform only one request per connection. If the user used one connection, multiple Paged Results requests were not supported. This update adds support for multiple Paged Results requests. - BZ#830355
- With this enhancement, obsolete elements in the Database Replica Update Vector (RUV) can be removed with the
CLEANRUVoperation, which removes them on a single supplier or master. - BZ#833222
- This enhancement improves the
memberOfplug-in to work across multiple back ends or suffixes. - BZ#834046
- With this update, the
Directory Serverschema has been updated with thensTLS1attribute to makeTLS/SSLconfiguration easier. - BZ#834049
- With this update, the
Directory Serverschema has been updated to include theDNAplug-in attributes. - BZ#834052
- This enhancement improves the
Access Controlfeature to control the Directory Manager account. - BZ#834053
- This enhancement adds the ability to execute internal modification operations without changing the operational
modifiersnameattribute. - BZ#834058
- With this update, the
logconv.plscript has been enhanced with thegetopts()function. - BZ#834060
- Previously, the password lockout process was triggered not when maximum the number of tries was reached, but the time after. This behavior was not consistent with other vendors' LDAP servers. This enhancement adds the new option which allows users to specify the behavior of password lockout.
- BZ#834061
- Previously, DS did not include the
SO_KEEPALIVEsettings and connections could not be closed properly. This enhancement implements theSO_KEEPALIVEsettings to the DS connections. - BZ#834063
- With this update, the new
passwordTrackUpdateTimeattribute has been added. This attribute records a timestamp when the password was last changed. - BZ#834074
- This enhancement adds the new
nsds5ReplicaEnabledattribute to the replication agreement. If the replication agreement is disabled, it appears to be removed, but can be easily re-enabled and resumed. - BZ#847868
- Previously, the
Windows Syncplug-in did not support the RFC 2307 and 2307bis types of POSIX schema which supports Windows Active Directory (AD). Under these circumstances, users had to synchronize data between AD and DS manually which could return errors. This enhancement changes the POSIX attributes to prevent these consequences.Note
Note, that for the initial release, when adding new user and group entries to the DS, the POSIX attributes are not synchronized with AD. Adding new user and group entries to AD synchronizes to DS, and modifying attributes synchronizes both ways. - BZ#852087
- This enhancement improves the
Directory Serverschema to allow setting up an access control for thensslapd-readonlyattribute.
All users of 389-ds-base are advised to upgrade to these updated packages, which correct this issue and provide numerous bug fixes and enhancements. After installing this update, the 389 server service will be restarted automatically.
7.1.2. RHSA-2013:1182 — Important: 389-ds-base security update Copiar enlaceEnlace copiado en el portapapeles!
Copiar enlaceEnlace copiado en el portapapeles!
Updated 389-ds-base packages that fix one security issue are now available for Red Hat Enterprise Linux 6.
The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link associated with the description below.
The 389 Directory Server is an LDAPv3 compliant server. The base packages include the Lightweight Directory Access Protocol (LDAP) server and command-line utilities for server administration.
Security Fix
- CVE-2013-4283
- It was discovered that the 389 Directory Server did not properly handle the receipt of certain MOD operations with a bogus Distinguished Name (DN). A remote, unauthenticated attacker could use this flaw to cause the 389 Directory Server to crash.
All 389-ds-base users are advised to upgrade to these updated packages, which contain a backported patch to correct this issue. After installing this update, the 389 server service will be restarted automatically.