Chapter 5. Bug fixes

This part describes bugs fixed in Red Hat Enterprise Linux 8.0 that have a significant impact on users.

5.1. Desktop

PackageKit can now operate on rpm packages

With this update, the support for operating on rpm packages has been added into PackageKit.

(BZ#1559414)

5.2. Graphics infrastructures

QEMU does not handle 8-byte ggtt entries correctly

QEMU occasionally splits an 8-byte ggtt entry write to two consecutive 4-byte writes. Each of these partial writes can trigger a separate host ggtt write. Sometimes the two ggtt writes are combined incorrectly. Consequently, translation to a machine address fails, and an error log occurs.

(BZ#1598776)

5.3. Identity Management

The Enterprise Security Client uses the opensc library for token detection

Red Hat Enterprise Linux 8.0 only supports the opensc library for smart cards. With this update, the Enterprise Security Client (ESC) use opensc for token detection instead of the removed coolkey library. As a result, applications correctly detect supported tokens.

(BZ#1538645)

Certificate System now supports rotating debug logs

Previously, Certificate System used a custom logging framework, which did not support log rotation. As a consequence, debug logs such as /var/log/pki/instance_name/ca/debug grew indefinitely. With this update, Certificate System uses the java.logging.util framework, which supports log rotation. As a result, you can configure log rotation in the /var/lib/pki/instance_name/conf/logging.properties file.

For further information on log rotation, see documentation for the java.util.logging package.

(BZ#1565073)

Certificate System no longer logs SetAllPropertiesRule operation warnings when the service starts

Previously, Certificate System logged warnings on the SetAllPropertiesRule operation in the /var/log/messages log file when the service started. The problem has been fixed, and the mentioned warnings are no longer logged.

(BZ#1424966)

The Certificate System KRA client parses Key Request responses correctly

Previously, Certificate System switched to a new JSON library. As a consequence, serialization for certain objects differed, and the Python key recovery authority (KRA) client failed to parse Key Request responses. The client has been modified to support responses using both the old and the new JSON library. As a result, the Python KRA client parses Key Request responses correctly.

(BZ#1623444)

5.4. Compilers and development tools

GCC no longer produces false positive warnings about out-of-bounds access

Previously, when compiling with the -O3 optimization level option, the GNU Compiler Collection (GCC) occasionally returned a false positive warning about an out-of-bounds access, even if the compiled code did not contain it. The optimization has been fixed and GCC no longer displays the false positive warning.

(BZ#1246444)

ltrace displays large structures correctly

Previously, the ltrace tool could not correctly print large structures returned from functions. Handling of large structures in ltrace has been improved and they are now printed correctly.

(BZ#1584322)

5.5. File systems and storage

Higher print levels no longer cause iscsiadm to terminate unexpectedly

Previously, the iscsiadm utility terminated unexpectedly when the user specified a print level higher than 0 with the --print or -P option. This problem has been fixed, and all print levels now work as expected.

(BZ#1582099)

5.6. High availability and clusters

New /etc/sysconfig/pcsd option to reject client-initiated SSL/TLS renegotiation

When TLS renegotiation is enabled on the server, a client is allowed to send a renegotiation request, which initiates a new handshake. Computational requirements of a handshake are higher on a server than on a client. This makes the server vulnerable to DoS attacks. With this fix, the setting PCSD_SSL_OPTIONS in the /etc/sysconfig/pcsd configuration file accepts the OP_NO_RENEGOTIATION option to reject renegotiations. Note that the client can still open multiple connections to a server with a handshake performed in all of them.

(BZ#1566430)

A removed cluster node is no longer displayed in the cluster status

Previously, when a node was removed with the pcs cluster node remove command, the removed node remained visible in the output of a pcs status display. With this fix, the removed node is no longer displayed in the cluster status.

(BZ#1595829)

Fence agents can now be configured using either newer, preferred parameter names or deprecated parameter names

A large number of fence agent parameters have been renamed while the old parameter names are still supported as deprecated. Previously, pcs was not able to set the new parameters unless used with the --force option. With this fix, pcs now supports the renamed fence agent parameters while maintaining support for the deprecated parameters.

(BZ#1436217)

The pcs command now correctly reads the XML status of a cluster for display

The pcs command runs the crm_mon utility to get the status of a cluster in XML format. The crm_mon utility prints XML to standard output and warnings to standard error output. Previously pcs mixed XML and warnings into one stream and was then unable to parse it as XML. With this fix, standard and error outputs are separated in pcs and reading the XML status of a cluster works as expected.

(BZ#1578955)

Users no longer advised to destroy clusters when creating new clusters with nodes from existing clusters

Previously, when a user specified nodes from an existing cluster when running the pcs cluster setup command or when creating a cluster with the pcsd Web UI, pcs reported that as an error and suggested that the user destroy the cluster on the nodes. As a result, users would destroy the cluster on the nodes, breaking the cluster the nodes were part of as the remaining nodes would still consider the destroyed nodes to be part of the cluster. With this fix, users are instead advised to remove nodes from their cluster, better informing them of how to address the issue without breaking their clusters.

(BZ#1596050)

pcs commands no longer interactively ask for credentials

When a non-root user runs a pcs command that requires root permission, pcs connects to the locally running pcsd daemon and passes the command to it, since the pcsd daemon runs with root permissions and is capable of running the command. Previously, if the user was not authenticated to the local pcsd daemon, pcs asked for a user name and a password interactively. This was confusing to the user and required special handling in scripts running pcs. With this fix, if the user is not authenticated then pcs exits with an error advising what to do: Either run pcs as root or authenticate using the new pcs client local-auth command. As a result, pcs commands do not interactively ask for credentials, improving the user experience.

(BZ#1554310)

The pcsd daemon now starts with its default self-generated SSL certificate when crypto-policies is set to FUTURE.

A crypto-policies setting of FUTURE requires RSA keys in SSL certificates to be at least 3072b long. Previously, the pcsd daemon would not start when this policy was set since it generates SSL certificates with a 2048b key. With this update, the key size of pcsd self-generated SSL certificates has been increased to 3072b and pcsd now starts with its default self-generated SSL certificate.

(BZ#1638852)

The pcsd service now starts when the network is ready

Previously, When a user configured pcsd to bind to a specific IP address and the address was not ready during boot when pcsd attempted to start up, then pcsd failed to start and a manual intervention was required to start pcsd. With this fix, pcsd.service depends on network-online.target. As a result, pcsd starts when the network is ready and is able to bind to an IP address.

(BZ#1640477)

5.7. Security

SELinux policy now allows iscsiuio processes to connect to the discovery portal

Previously, SELinux policy was too restrictive for iscsiuio processes and these processes were not able to access /dev/uio* devices using the mmap system call. As a consequence, connection to the discovery portal failed. This update adds the missing rules to the SELinux policy and iscsiuio processes work as expected in the described scenario.

(BZ#1626446)

5.8. Virtualization

Mounting ephemeral disks on Azure now works more reliably

Previously, mounting an ephemeral disk on a virtual machine (VM) running on the Microsoft Azure platform failed if the disk was detached from the VM shortly before. This update ensures that reconnecting disks is handled correctly in the described circumstances, which prevents the problem from occurring.

(BZ#1615599)