RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1776408 - Ambiguous error returned preventing user from understanding the root cause of the error
Summary: Ambiguous error returned preventing user from understanding the root cause of...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.2
Assignee: David Tardon
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-25 16:03 UTC by Renaud Métrich
Modified: 2023-02-12 22:43 UTC (History)
9 users (show)

Fixed In Version: systemd-239-23.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:45:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github systemd systemd pull 11513 0 None closed improve cryptsetup messaging 2020-09-03 09:04:23 UTC
Github systemd systemd pull 9420 0 None closed crypt-util: Translate libcryptsetup log level instead of using log_debug() 2020-09-03 09:04:23 UTC
Red Hat Issue Tracker RHELPLAN-30476 0 None None None 2023-02-12 22:43:19 UTC
Red Hat Product Errata RHSA-2020:1794 0 None None None 2020-04-28 16:45:56 UTC

Description Renaud Métrich 2019-11-25 16:03:30 UTC 
Description of problem:

When attaching a LUKS device using a key file (e.g. /dev/urandom for swap) and the LUKS device is already used, the _activate_loopaes() function returns in error but no message is printed, preventing the caller (e.g. systemd-cryptsetup) to return a proper message.


cryptsetup-2.2.0/lib/setup.c:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
4045 int crypt_activate_by_keyfile_device_offset(struct crypt_device *cd,
 :
4068         r = crypt_keyfile_device_read(cd, keyfile,
4069                                 &passphrase_read, &passphrase_size_read,
4070                                 keyfile_offset, keyfile_size, 0);
4071         if (r < 0)
4072                 goto out;
 :
4074         if (isLOOPAES(cd->type))
4075                 r = _activate_loopaes(cd, name, passphrase_read, passphrase_size_read, flags);
4076         else
4077                 r = _activate_by_passphrase(cd, name, keyslot, passphrase_read, passphrase_size_read     , flags);
 :
4079 out:
4080         crypt_safe_free(passphrase_read);
4081         return r;
4082 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Lines 4075 and 4077 above: usually EBUSY will be returned here without explanation.
Line 4068: usually EINVAL will be returned here without explanation.

This leads to systemd-cryptsetup to print a non-sense message:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Failed to activate with key file '/dev/urandom': Device or resource busy
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The EBUSY is on the device, not the key file.


Version-Release number of selected component (if applicable):

cryptsetup-2.2.0-2.el8.x86_64


How reproducible:

Always


Steps to Reproduce:
1. Boot a system with unencrypted swap device (/dev/mapper/rhel-swap)
2. Execute systemd-cryptsetup

  # /usr/lib/systemd/systemd-cryptsetup attach swap-enc /dev/mapper/rhel-swap /dev/urandom swap


Actual results:

"
Failed to activate with key file '/dev/urandom': Device or resource busy
"


Expected results:

Some proper error message, e.g. "/dev/mapper/rhel-swap: device is busy"


Additional info:

The issue happens when the admin tries to "convert" a regular swap device into an encrypted swap device after installation occurred.
If the admin didn't deactivate the swap device before setting it for encryption (KCS https://access.redhat.com/solutions/1121603), systemd-cryptsetup@<dev>.service unit will fail with "Failed to activate with key file '/dev/urandom': Device or resource busy".
This was hard to find out what was going on due to the generic message seen there.


Additionally, if an invalid key file is submitted (e.g. "/non-existing"), another generic message is seen:

"
Failed to activate with key file '/non-existing': Invalid argument
"
Comment 1 Ondrej Kozina 2019-11-25 16:56:26 UTC 
I think that error message should be fixed on systemd-cryptsetup side. It should interpret -EBUSY return code from libcryptsetup not for a keyfile but data device instead.

For example with cryptsetup cli I get following:

[root@machine /]# mount /dev/sdc /mnt/blabla
[root@machine /]# cryptsetup open --type plain /dev/sdc --key-file /dev/urandom sdc_crypt
Cannot use device /dev/sdc which is in use (already mapped or mounted).
Comment 2 Renaud Métrich 2019-11-25 17:05:20 UTC 
Indeed, sorry for the noise, everything is fine on cryptsetup's side.
But systemd's cryptsetup_log_glue() is broken, it logs everything at DEBUG level:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  7 void cryptsetup_log_glue(int level, const char *msg, void *usrptr) {
  8         log_debug("%s", msg);
  9 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Comment 3 Renaud Métrich 2019-11-25 17:24:38 UTC 
Probably the cryptsetup_log_glue() function should be modified to store the message somewhere for processing by the caller (only the caller can decide whether there is actually a failure).

Additionally, when it goes with setting up the swap device with /dev/urandom, it is non-sense to retry the command interactively, as currently seen:

(usually done by generated systemd-crypsetup):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# /usr/lib/systemd/systemd-cryptsetup attach swap-enc /dev/mapper/rhel-swap /dev/urandom swap
Failed to activate with key file '/dev/urandom': Device or resource busy
Please enter passphrase for disk rhel-swap (swap-enc) on swap! 
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

--> That "Please enter passphrase ..." message shouldn't happen when the issue is on the device being busy (not the key file having an issue).
Comment 4 Renaud Métrich 2019-11-26 08:24:57 UTC 
We at least need to backport this:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
commit aa2cc005d77890b07e8c579f25e1333ff8ba8dac
Author: Jan Janssen <medhefgo>
Date:   Mon Jun 25 20:33:31 2018 +0200

    crypt-util: Translate libcryptsetup log level instead of using log_debug()
    
    This makes sure that errors reported by libcryptsetup are shown to the
    user instead of getting swallowed up by log_debug().
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This commit logs at appropriate level.
Comment 5 Renaud Métrich 2019-11-28 09:10:43 UTC 
The fix should consist of 2 parts:
1. backporting aa2cc005d77890b07e8c579f25e1333ff8ba8dac
2. not asking for password if error is "device busy" (there is no point in asking for password in such case)

So it's not so easy fix, but almost :-)
Comment 6 David Tardon 2019-12-12 16:39:58 UTC 
PR: https://github.com/systemd-rhel/rhel-8/pull/52
Comment 12 errata-xmlrpc 2020-04-28 16:45:29 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1794
Note You need to log in before you can comment on or make changes to this bug.