Questo contenuto non è disponibile nella lingua selezionata.
Chapter 7. Updated Packages
7.1. 389-ds-base
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=config
suffix, when an attribute value was deleted and then added back in the same modify operation,error 53
was 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.pl
script 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 Sync
feature uses the name in a search filter to perform an internal search to find an entry. Parentheses, “(” and “)” are special characters in theLDAP
protocol 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 Sync
feature, the DS entry was deleted. This update adds the newwinSyncMoveAction
DS 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 full
error 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
ldif
file 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_DEADLOCK
error messages appeared in the error log:entryrdn-index - _entryrdn_put_data: Adding the parent link (XXX) failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)
These errors are common under these circumstances and there is no need to report them in the error log. With this update,389 Directory Server
ensures 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 USN
plug-in, the delete operation was not replicated to the other masters. This update modifies theEntry USN
plug-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 Entry
plug-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 Entry
plug-in. Themanager
entry was deleted, but themanaged
entry 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 Entry
plug-in or theDNA
plug-in, thevalgrind
tool 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-deleted
attribute 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 Modify
operations, can cause the 389 Directory Server to modify internal attributes. For example, aBIND
operation can cause updates to password failure counters. In these cases, 389 Directory Server was updating attributes that could only be updated during an explicitLDAP Modify
operation, such as themodifyTimestamp
attribute. This update adds a new internal flag to skip the update of these attributes on other thanModify
operations. - BZ#834056
- Due to an invalid configuration setup in the
Auto Memmber
plug-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
ldap
servers listed in theldap-agent.conf
file. With this update, the buffer betweenldap
servers no longer resets and 389 Directory Server starts up regardless of the number ofldap
servers listed in the configuration file. - BZ#834064
- Previously, the
dnaNextValue
counter was incremented in the pre-operation stage. Consequently, if the operation failed, the counter was still incremented. This bug has been fixed and thednaNextValue
counter 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.pl
script 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.pl
now grabs the correct search base and no longer produces incorrect statistics. - BZ#838706
- When using the
Referential Integrity
plug-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 Uniqueness
plug-in did comparisons of un-normalized values. Consequently, using this plug-in and performing theLDAP RENAME
operation on an entry containing one of the attributes which were tested for uniqueness by this plug-in caused theLDAP RENAME
operation to fail with the following error:Constraint Violation - Another entry with the same attribute value already exists.
With this update,Attribute Uniqueness
ensures that comparisons are performed between values which were normalized the same way, andLDAP RENAME
works as expected in this situation. - BZ#841600
- When the
Referential Integrity
plug-in was used with a delay time greater than 0, and theLDAP RENAME
operation was performed on auser
entry with DN specified by one or moregroup
entries under the scope of theReferential Integrity
plug-in, the user entry DN in thegroup
entries did not change. The underlying source code has been modified andLDAP RENAME
operations work as expected in the described scenario. - BZ#842437
- Previously, the
DNA
plug-in could leak memory in certain cases for certainMODIFY
operations. 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
Memberof
plug-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
nsds5ReplicaStripAttrs
attribute using theldapmodify
operation. Consequently, the attribute could only be set manually in thedse.ldif
file when the server was shut down. With this update, the user is now able to set thensds5ReplicaStripAttrs
attribute using theldapmodify
operation. - BZ#850683
- Previously, 389 Directory Server did not check attribute values for the
nsds5ReplicaEnabled
feature which caused this feature to be disabled. With this update, 389 Directory Server checks if the attribute value fornsds5ReplicaEnabled
is valid and reports an error if it is not. - BZ#852088
- When multi-master replication or database chaining was used with the
TLS/SSL
protocol, 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
cleanallruv
task to the Windows WinSync replication agreements, the task became unresponsive. With this update, the WinSync replication agreements are ignored and thecleanallruv
task no longer hangs in the described scenario. - BZ#856657
- Previously, the
dirsrv
init 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 anddirsrv
no 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 server
has several internal schemas which are not stored in the schema directory. These schemas were lost after the schema reload task was executed. Consequently, adding aposixAccount
class failed. With this update, the internal schemas are stashed in a hash table and reloaded with external schemas. As result, adding aposixAccount
is 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 Sync
feature 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:detected win2k3 peer
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 or later peer
- BZ#870158
- When a directory server was under a heavy load, deleting entries using the
Entry USN
feature 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
DNA
plug-in attempted to dereference a NULL pointer value for thednaMagicRegen
attribute. Consequently, ifDNA
was enabled with nodnamagicregen
value 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 emptydnamagicregen
value before it attempts to dereference this value. As a result, 389 Directory Server no longer crashes if nodnamagicregen
attribute 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
modrdn
operation 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 themodrdn
operation 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_fetch
attribute 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 toALLID
mode by using thensslapd-rangelookthroughlimit
switch 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-binddn
feature filled the value of theinternalModifiersname
andinternalCreatorsname
attributes 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-binddn
has 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
DNA
plug-in when the range of values was depleted caused the following error message to be returned: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.
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. - 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-through
plug-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
automember
plug-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
modifiersname
ormodifystimestamp
attribute to be updated. This behavior led to unnecessary replication traffic. This enhancement introduces the newreplication
feature to decrease replication traffic caused by BINDs. - BZ#830331
- This enhancement adds the new
Disk Monitoring
plug-in. When disk partitions fill up,Disk Monitoring
returns 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
Cleanallruv
feature. - BZ#830347
- Previously, the
Paged Results
search 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
CLEANRUV
operation, which removes them on a single supplier or master. - BZ#833222
- This enhancement improves the
memberOf
plug-in to work across multiple back ends or suffixes. - BZ#834046
- With this update, the
Directory Server
schema has been updated with thensTLS1
attribute to makeTLS/SSL
configuration easier. - BZ#834049
- With this update, the
Directory Server
schema has been updated to include theDNA
plug-in attributes. - BZ#834052
- This enhancement improves the
Access Control
feature to control the Directory Manager account. - BZ#834053
- This enhancement adds the ability to execute internal modification operations without changing the operational
modifiersname
attribute. - BZ#834058
- With this update, the
logconv.pl
script 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_KEEPALIVE
settings and connections could not be closed properly. This enhancement implements theSO_KEEPALIVE
settings to the DS connections. - BZ#834063
- With this update, the new
passwordTrackUpdateTime
attribute has been added. This attribute records a timestamp when the password was last changed. - BZ#834074
- This enhancement adds the new
nsds5ReplicaEnabled
attribute 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 Sync
plug-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 Server
schema to allow setting up an access control for thensslapd-readonly
attribute.
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.
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.