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 1226333 - systemd ask-password generates inconsistent IDs
Summary: systemd ask-password generates inconsistent IDs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Alois Mahdal
URL:
Whiteboard:
Depends On:
Blocks: 1205440
TreeView+ depends on / blocked
 
Reported: 2015-05-29 13:12 UTC by Nathaniel McCallum
Modified: 2015-11-19 15:06 UTC (History)
6 users (show)

Fixed In Version: systemd-219-4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 15:06:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2092 0 normal SHIPPED_LIVE systemd bug fix and enhancement update 2015-11-19 12:13:57 UTC

Description Nathaniel McCallum 2015-05-29 13:12:14 UTC 
This means that password agents don't know what format to receive, making parsing especially complex. This should be simplified to a standard, consistent format.

A patch is available:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032478.html
Comment 2 Lukáš Nykrýn 2015-06-01 08:20:54 UTC 
Should be easy to backport after patch hits upstream-
Comment 3 Lukáš Nykrýn 2015-06-09 11:42:35 UTC 
https://github.com/lnykryn/systemd-rhel/commit/6c45bdd261e027ea78eabb81feaa70f3774bcf2f
Comment 5 Alois Mahdal 2015-08-18 16:16:20 UTC 
From what I understood from referenced thread, an ID= item in INI should now have different format (involving maj:min) than in the past.

But the changes seem to only be about cryptsetup.  How does systemd-ask-password fit in?

What I tried:

 *  `systemd-ask-password --no-tty foo` and check the INI (in /run...)

    but there was no ID= ... as expected, given that cryptsetup was not
    involved.

 *  luksFormat a /dev/loop0 device and `cryptsetup open` it, but I can't get
    cryptsetup use sytemd-ask-password.  I'm not sure this is the right way
    to reproduce this, though.
Comment 6 Harald Hoyer 2015-10-12 11:36:02 UTC 
(In reply to Alois Mahdal from comment #5)
> From what I understood from referenced thread, an ID= item in INI should now
> have different format (involving maj:min) than in the past.
> 
> But the changes seem to only be about cryptsetup.  How does
> systemd-ask-password fit in?
> 
> What I tried:
> 
>  *  `systemd-ask-password --no-tty foo` and check the INI (in /run...)
> 
>     but there was no ID= ... as expected, given that cryptsetup was not
>     involved.
> 
>  *  luksFormat a /dev/loop0 device and `cryptsetup open` it, but I can't get
>     cryptsetup use sytemd-ask-password.  I'm not sure this is the right way
>     to reproduce this, though.

Untested, but should be testable like this:
* luksFormat a /dev/loop0 device
* create an entry for it in /etc/crypttab
* systemctl daemon-reload
to let the cryptsetup generator run
* systemctl start cryptsetup.target
or restart
* check the *.ini files
Comment 7 Alois Mahdal 2015-10-12 13:34:02 UTC 
So far, trying simple setup with loop device, on x86_64 (1minutetip opeshift box).

During `systemctl start cryptsetup.target` (not entering password, but opening other connection):

    # cat /run/systemd/ask-password/ask.yVdmPu 
    [Ask]
    PID=6018
    Socket=/run/systemd/ask-password/sck.1ca29e417eecff2
    AcceptCached=1
    Echo=0
    NotAfter=0
    Message=Please enter passphrase for disk foo on /foo!
    Icon=drive-harddisk
    Id=cryptsetup:/dev/block/7:0
    # 

Seems OK so far but I did not try the fallback scenario mentioned ih the reference thread:

> If possible "/dev/block/<maj>:<min>" is used, otherwise the original
> argv[3] is used.

Looking into it (plus other archs)...
Comment 8 Alois Mahdal 2015-10-14 06:01:44 UTC 
So I have checked the above on  rest of archs and so far all looks OK.

One more thing:

Do you know how to reproduce the alternative when "/dev/block/<maj>:<min>" cannot be used?  Is it possible within RHEL kernel and its settings?
Comment 9 Harald Hoyer 2015-11-11 09:00:01 UTC 
(In reply to Alois Mahdal from comment #8)
> So I have checked the above on  rest of archs and so far all looks OK.
> 
> One more thing:
> 
> Do you know how to reproduce the alternative when "/dev/block/<maj>:<min>"
> cannot be used?  Is it possible within RHEL kernel and its settings?

Remove "/dev/block/<maj>:<min>" before issuing  `systemctl start cryptsetup.target`. With <maj>:<min> of the loop device.
Comment 10 errata-xmlrpc 2015-11-19 15:06:32 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://rhn.redhat.com/errata/RHBA-2015-2092.html
Note You need to log in before you can comment on or make changes to this bug.