Debian Bug report logs - #618862
systemd: ignores keyscript in crypttab

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mourad De Clerck <debian-bugs@aquazul.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: systemd: ignores keyscript in crypttab

Date: Sat, 19 Mar 2011 03:40:25 +0100

Package: systemd
Version: 19-1
Severity: normal

Hi,

my root and swap partition are encrypted with cryptsetup; root uses a custom
keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
systemd seems to be unable to work with keyscripts at all, and requires
password input for every volume that wasn't activated already. Luckily, my
root FS is activated by the initramfs.

I don't want to have to type in a password for every encrypted volume: on
some of my machines this would mean having to type five or more passwords on
boot.

Is there any way of using keyscripts or some equivalent with systemd?


FYI, some (abbreviated) info on my machine.


/etc/fstab:

/dev/mapper/root  /     ext3  relatime,user_xattr,errors=remount-ro 0   1
/dev/sda1         /boot ext3  noatime                               0   2
/dev/mapper/swap  none  swap  sw                                    0   0


/etc/crypttab:

root    UUID=...  /dev/...  luks,keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev
swap    UUID=...  root      luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived


/var/log/syslog:

systemd-initctl[10973]: Received environment initctl request. This is not implemented in systemd.
systemd-fsck[452]: root: clean, 444366/13107200 files, 47184313/52427870 blocks
systemd-cryptsetup[735]: Encountered unknown /etc/crypttab option 'keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev', ignoring.
systemd-cryptsetup[735]: Volume root already active.
systemd-cryptsetup[781]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[781]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-fsck[738]: /dev/sda1: clean, 255/65952 files, 57208/263056 blocks
systemd-cryptsetup[781]: Invalid packet
systemd-cryptsetup[781]: Timed out
systemd-cryptsetup[781]: Failed to query password: Timer expired
systemd-cryptsetup[1102]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[1102]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-cryptsetup[1102]: Timed out
systemd-cryptsetup[1102]: Failed to query password: Timer expired
systemd-cryptsetup[1399]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[1399]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-cryptsetup[1399]: Timed out
systemd-cryptsetup[1399]: Failed to query password: Timer expired



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  libaudit0                    1.7.13-1+b2 Dynamic library for security audit
ii  libc6                        2.11.2-13   Embedded GNU C Library: Shared lib
ii  libcap2                      1:2.20-1    support for getting/setting POSIX.
ii  libcryptsetup1               2:1.2.0-2   libcryptsetup shared library
ii  libdbus-1-3                  1.4.6-1     simple interprocess messaging syst
ii  libpam0g                     1.1.2-2     Pluggable Authentication Modules l
ii  libselinux1                  2.0.96-1    SELinux runtime shared libraries
ii  libudev0                     166-1       libudev shared library
ii  util-linux                   2.17.2-9.1  Miscellaneous system utilities

Versions of packages systemd recommends:
ii  libpam-systemd                19-1       system and service manager - PAM m

Versions of packages systemd suggests:
ii  systemd-gui                   19-1       system and service manager - GUI

-- no debconf information

Message #12 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 618862@bugs.debian.org, bugs-debian@aquazul.com

Subject: systemd: ignores keyscript in crypttab

Date: Mon, 06 Feb 2012 10:24:11 +0100

[Message part 1 (text/plain, inline)]

http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n45

/* Options Debian's crypttab knows we don't:

    offset=
    skip=
    precheck=
    check=
    checkargs=
    noearly=
    loud=
    keyscript=
*/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Harald Jenny <harald@a-little-linux-box.at>

To: 618862@bugs.debian.org

Subject: systemd: ignores keyscript in crypttab - possibilities to solve this issue

Date: Tue, 25 Jun 2013 13:13:13 +0200

Dear Michael Biebl,

following the systemd survey and discussion I think these mails might be
of interest to you concerning possible ways to solve the current issue
(not only in Debian but also SuSE/upstream interest).

http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835

Kind regards
Harald Jenny

Message #24 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Harald Jenny <harald@a-little-linux-box.at>, 618862@bugs.debian.org

Cc: David Härdeman <david@hardeman.nu>

Subject: Re: [Pkg-systemd-maintainers] Bug#618862: systemd: ignores keyscript in crypttab - possibilities to solve this issue

Date: Tue, 25 Jun 2013 17:47:19 +0200

[Message part 1 (text/plain, inline)]

Am 25.06.2013 13:13, schrieb Harald Jenny:
> Dear Michael Biebl,
> 
> following the systemd survey and discussion I think these mails might be
> of interest to you concerning possible ways to solve the current issue
> (not only in Debian but also SuSE/upstream interest).
> 
> http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
> http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835

I personally don't own such hardware, and I never have userd
cryptsetup's keyscript support. So I'm probably not the most qualified
to evaluate the situation.
That said, reading the upstream discussion, I guess we have 3 options
a/ do nothing about it
b/ apply the patch from David Härdeman downstream and maintaining it as
a downstream patch forever
c/ try to implement keyscript support based on the PasswordAgent interface

a/ is obviously not very compelling. As for b/, we try to avoid
downstream patches as much as possible.
Regarding c/, I dunno how much effort that would be.

Bringing David into the loop here. Maybe he has some further insight on
this matter.

Tollef, what's your take on this?


cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #29 received at 618862@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Michael Biebl <biebl@debian.org>

Cc: Harald Jenny <harald@a-little-linux-box.at>, 618862@bugs.debian.org

Subject: Re: [Pkg-systemd-maintainers] Bug#618862: systemd: ignores keyscript in crypttab - possibilities to solve this issue

Date: Thu, 4 Jul 2013 22:09:36 +0200

On Tue, Jun 25, 2013 at 05:47:19PM +0200, Michael Biebl wrote:
>Am 25.06.2013 13:13, schrieb Harald Jenny:
>> Dear Michael Biebl,
>> 
>> following the systemd survey and discussion I think these mails might be
>> of interest to you concerning possible ways to solve the current issue
>> (not only in Debian but also SuSE/upstream interest).
>> 
>> http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
>> http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835
>
>I personally don't own such hardware, and I never have userd
>cryptsetup's keyscript support. So I'm probably not the most qualified
>to evaluate the situation.

You don't actually need any hardware though. A keyscript (for a testing
environment) could simply echo a fixed password and be used to decrypt a
loopback device.

>That said, reading the upstream discussion, I guess we have 3 options
>a/ do nothing about it
>b/ apply the patch from David Härdeman downstream and maintaining it as
>a downstream patch forever
>c/ try to implement keyscript support based on the PasswordAgent interface
>
>a/ is obviously not very compelling. As for b/, we try to avoid
>downstream patches as much as possible.
>Regarding c/, I dunno how much effort that would be.
>
>Bringing David into the loop here. Maybe he has some further insight on
>this matter.

I still think it's too early to rule out option c). Contrary to what
some other people seem to think, I don't find Lennart difficult to work
with (not more so than any other average upstream).

It would probably be a lot of work though since a good solution would
probably need further additions to the PasswordAgent API (to name but
one problem, imagine a keyscript that would in turn fetch a key from a
smartcard and which needed to get the PIN from the user...it would in
effect require two calls through the PasswordAgent stack but only one
prompt - the one for the PIN - should be displayed to the user).

I don't believe that I will have the time to implement and drive a
change of that scope in the foreseeable future...

-- 
David Härdeman

Message #34 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 618862@bugs.debian.org

Subject: Re: systemd: ignores keyscript in crypttab

Date: Wed, 01 Jan 2014 20:03:36 +0100

[Message part 1 (text/plain, inline)]

Hi.

Had a private conversation with Tollef and he pointed me to this bug...

Even though it may be obvious to any developer, let me add the
following:
I had a short glance at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n54
I guess another crypt_activate_by_? function would need to be
implemented for keyscripts.

One thing which need to be taken into account is the following:

The keyscript is an arbitrary program (no necessarily a shell script...
and the key file parameter (the 3rd field in crypttab(5)) may _not_ be a
pathname at all.
I for example use a keyscript for openpgp encrypted keys (a different
one from that shipped in Debian, which has several functionality
deficiencies and following from that: security issues) where one would
see lines as the following in crypttab:

root   /dev/disk/by-uuid/74b4564a-728e-11e3-8a8d-502690aa641f   device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root   loud,luks,keyscript=decrypt_openpgp,tries=0

All of this is "normal" unless the 3rd field:
device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root
which is given to my keyscript decrypt_openpgp

It basically combines two options (separated by a colon) into the one
passed to the keyscript (which splits it again)...
device= being a filesystem which the keyscript should wait to appear
(i.e. a USB stick)... mount it ... and
pathname= being a a file local to the filesystem on that device... which
is then read, fed through gpg and so on.

And this is just one example where one could need multiple options put
together in the keyfile field of crypttab - unfortunately the Debian
maintainer refused to standardise this.

Another example could be a OpenPGP crypto smart card, where one waits
for a specific smart card ID to appear, and reads key number n from it.
Or one can think of examples where the key is read via secured network
connections (ssh, ipsec, whatever) and where multiple parameters would
be required.


So the point is... any support for keyscripts in systemd MUST NOT try to
be smarter than it should and somehow interpreting or modifying the
keyfile field.
It simply MUST pass that on the the keyscript, just as the Debian
cryptsetup scripts do it.

And it should be noted, that the cryptsetup scripts initialise a bunch
of environment variables for the executed keyscript program, which of
course systemd would need to do as well.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #39 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 618862@bugs.debian.org

Subject: Re: systemd: ignores keyscript in crypttab

Date: Wed, 01 Jan 2014 20:11:49 +0100

[Message part 1 (text/plain, inline)]

Oh and I forget (but it seems this is already clear as well):

keyscripts may make use of arbitrary other programs... OpenSSL, pcscd,
gpg, etc. pp.
I've just attached my own keyscript to give an example (just the script,
not the initramfs-tools hook or documentation).

The biggest problem is likely stuff that requires terminal input (AFAIU
systemd takes this over or at least should do so).
In Debians cryptsetup, there's /lib/cryptsetup/askpass which I for
example use to gather the passphrase (which is used to decrypt the
OpenPGP encrypted actual key).

So I guess that needs to be adapted somehow as well... either this, or
properly documented how to do things in the systemd-way.
And of course, any keyscripts would then need to support both,... a
systemd-way of interactive input (if there is any)... and the
traditional via e.g. askpass (AFAIU, the tech-ctte decision will just
define a new default init,... but not forbid any others).


Cheers,
Chris.

[decrypt_openpgp (application/x-shellscript, attachment)]

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #44 received at 618862@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Michael Biebl <biebl@debian.org>

Cc: Harald Jenny <harald@a-little-linux-box.at>, 618862@bugs.debian.org, systemd-devel@lists.freedesktop.org

Subject: Re: Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Thu, 30 Jan 2014 10:40:01 +0100

On 2013-06-25 17:47, Michael Biebl wrote:
> Am 25.06.2013 13:13, schrieb Harald Jenny:
>> Dear Michael Biebl,
>> 
>> following the systemd survey and discussion I think these mails might 
>> be
>> of interest to you concerning possible ways to solve the current issue
>> (not only in Debian but also SuSE/upstream interest).
>> 
>> http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
>> http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835
> 
> I personally don't own such hardware, and I never have userd
> cryptsetup's keyscript support. So I'm probably not the most qualified
> to evaluate the situation.
> That said, reading the upstream discussion, I guess we have 3 options
> a/ do nothing about it
> b/ apply the patch from David Härdeman downstream and maintaining it as
> a downstream patch forever
> c/ try to implement keyscript support based on the PasswordAgent 
> interface
> 
> a/ is obviously not very compelling. As for b/, we try to avoid
> downstream patches as much as possible.
> Regarding c/, I dunno how much effort that would be.
> 
> Bringing David into the loop here. Maybe he has some further insight on
> this matter.

I found some time to consider how to solve this and I think I have a 
pretty good solution that'd require a minimum amount of changes 
upstream.

What I've hacked together is:

First, a patch to the "askpass" binary in cryptsetup (the Debian 
package, not systemd's own stuff) so that it'll detect that systemd is 
running, in which case it'll use systemd's own password agent system for 
requesting a password from the user.

Second, a new systemd password agent. It waits for a password request 
from systemd's own cryptsetup implementation. The password agent then 
re-parses /etc/crypttab to find the corresponding entry and checks if it 
includes a keyscript= option. If no keyscript option is present the 
agent does nothing but if it *is* present, the agent recreates the 
environment created by the current cryptsetup scripts, launches the 
keyscript and sends the output back via the appropriate socket provided 
by systemd.

That the changes to "askpass" and the introduction of the new password 
agent are unrelated but both are necessary to not break existing 
keyscripts. "askpass" is used in keyscripts to get an actual key from 
the user. The password agent makes sure that systemd's own cryptsetup 
stuff honors the keyscript.

The new agent is not production ready yet (I plan to do some more work 
on it during FOSDEM), the two most important issues are:

a) getting the name of the cryptdev that the password request 
corresponds to currently involves parsing the prompt message ("Please 
enter passphrase for disk %s!") which is obviously not a real 
solution...

This issue is fixable with minor upstream changes, e.g. by extending the 
PasswordAgent protocol to add "Subsystem=cryptsetup" and 
"Target=<diskname>" entries to the "ask.xxxx" file.

b) the password agent implementation in systemd doesn't seem to handle 
binary strings (i.e. strings with '\0'), as can be seen by calls to e.g. 
"strlen()"...

Whether making it binary safe would be a major change or not is 
something I haven't researched yet but it seems like a change that 
should be generally useful upstream...



Minor detail: the additional agent could be shipped either in (I have no 
real preference):

a) the cryptsetup package

b) as part of the Debian systemd package

c) upstream systemd


Feedback welcome.

Regards,
David

[1] http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/

Message #49 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Lennart Poettering <lennart@poettering.net>

To: David Härdeman <david@hardeman.nu>

Cc: Michael Biebl <biebl@debian.org>, Harald Jenny <harald@a-little-linux-box.at>, systemd-devel@lists.freedesktop.org, 618862@bugs.debian.org

Subject: Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Wed, 5 Feb 2014 00:16:00 +0100

On Thu, 30.01.14 10:40, David Härdeman (david@hardeman.nu) wrote:

> a) getting the name of the cryptdev that the password request
> corresponds to currently involves parsing the prompt message
> ("Please enter passphrase for disk %s!") which is obviously not a
> real solution...
> 
> This issue is fixable with minor upstream changes, e.g. by extending
> the PasswordAgent protocol to add "Subsystem=cryptsetup" and
> "Target=<diskname>" entries to the "ask.xxxx" file.

I'd be fine with adding a field "Id=" or so, which then is filled by an
identifier of some kind be the cryptsetup tool that is useful to
identify the device to query things on. for example:
"Id=cryptsetup:/dev/sda5" or so could be one way how this could be
filled in. We wouldn't enfoce any kind of syntax on this, just suggest
some common sense so that people choose identifiers that are unlikely to
clash with other subsystems, and somewhat reasonable to read...

> b) the password agent implementation in systemd doesn't seem to
> handle binary strings (i.e. strings with '\0'), as can be seen by
> calls to e.g. "strlen()"...
> 
> Whether making it binary safe would be a major change or not is
> something I haven't researched yet but it seems like a change that
> should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.

> a) the cryptsetup package
> 
> b) as part of the Debian systemd package
> 
> c) upstream systemd

I'd prefer to keep this tool in a Debian-specific package. I am not
convinced that the key script thing is something we should standardize
on cross-distributions.

Lennart

-- 
Lennart Poettering, Red Hat

Message #54 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: Lennart Poettering <lennart@poettering.net>

Cc: David Härdeman <david@hardeman.nu>, Michael Biebl <biebl@debian.org>, Harald Jenny <harald@a-little-linux-box.at>, systemd-devel@lists.freedesktop.org, 618862@bugs.debian.org

Subject: Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Wed, 05 Feb 2014 14:23:14 +0100

]] Lennart Poettering 

> > a) the cryptsetup package
> > 
> > b) as part of the Debian systemd package
> > 
> > c) upstream systemd
> 
> I'd prefer to keep this tool in a Debian-specific package. I am not
> convinced that the key script thing is something we should standardize
> on cross-distributions.

I think it makes sense to push upstream, but as long as it's reasonably
self-contained I don't mind having it in Debian, either in the systemd
package or (if the cryptsetup maintainer wants it) in cryptsetup.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #59 received at 618862@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Lennart Poettering <lennart@poettering.net>

Cc: Michael Biebl <biebl@debian.org>, Harald Jenny <harald@a-little-linux-box.at>, systemd-devel@lists.freedesktop.org, 618862@bugs.debian.org

Subject: Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Sat, 8 Feb 2014 21:07:04 +0100

On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
>On Thu, 30.01.14 10:40, David Härdeman (david@hardeman.nu) wrote:
>> This issue is fixable with minor upstream changes, e.g. by extending
>> the PasswordAgent protocol to add "Subsystem=cryptsetup" and
>> "Target=<diskname>" entries to the "ask.xxxx" file.
>
>I'd be fine with adding a field "Id=" or so, which then is filled by an
>identifier of some kind be the cryptsetup tool that is useful to
>identify the device to query things on. for example:
>"Id=cryptsetup:/dev/sda5" or so could be one way how this could be
>filled in. We wouldn't enfoce any kind of syntax on this, just suggest
>some common sense so that people choose identifiers that are unlikely to
>clash with other subsystems, and somewhat reasonable to read...

In the patches I sent I split it into "Purpose" and "Target" and my
thinking was more or less the same as yours...i.e. that there's no
particular syntax and that the meaning of the string is subsystem
specific.

I'd be happy to change the patch to use "Id=<subsystem>:<target>" if
you'd prefer.

>> b) the password agent implementation in systemd doesn't seem to
>> handle binary strings (i.e. strings with '\0'), as can be seen by
>> calls to e.g. "strlen()"...
>> 
>> Whether making it binary safe would be a major change or not is
>> something I haven't researched yet but it seems like a change that
>> should be generally useful upstream...
>
>I'd be OK with this, as discussed at FOSDEM, and I see you already
>posted a ptach for this.

Yes. I take it you're pretty busy with the kdbus stuff right now but a
review of those patches would be nice when you have the time.

-- 
David Härdeman

Message #64 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Lennart Poettering <lennart@poettering.net>

To: David Härdeman <david@hardeman.nu>

Cc: Michael Biebl <biebl@debian.org>, Harald Jenny <harald@a-little-linux-box.at>, systemd-devel@lists.freedesktop.org, 618862@bugs.debian.org

Subject: Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Tue, 11 Feb 2014 12:29:16 +0100

On Sat, 08.02.14 21:07, David Härdeman (david@hardeman.nu) wrote:

> 
> On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
> >On Thu, 30.01.14 10:40, David Härdeman (david@hardeman.nu) wrote:
> >> This issue is fixable with minor upstream changes, e.g. by extending
> >> the PasswordAgent protocol to add "Subsystem=cryptsetup" and
> >> "Target=<diskname>" entries to the "ask.xxxx" file.
> >
> >I'd be fine with adding a field "Id=" or so, which then is filled by an
> >identifier of some kind be the cryptsetup tool that is useful to
> >identify the device to query things on. for example:
> >"Id=cryptsetup:/dev/sda5" or so could be one way how this could be
> >filled in. We wouldn't enfoce any kind of syntax on this, just suggest
> >some common sense so that people choose identifiers that are unlikely to
> >clash with other subsystems, and somewhat reasonable to read...
> 
> In the patches I sent I split it into "Purpose" and "Target" and my
> thinking was more or less the same as yours...i.e. that there's no
> particular syntax and that the meaning of the string is subsystem
> specific.
> 
> I'd be happy to change the patch to use "Id=<subsystem>:<target>" if
> you'd prefer.

Yes, please!

> >> b) the password agent implementation in systemd doesn't seem to
> >> handle binary strings (i.e. strings with '\0'), as can be seen by
> >> calls to e.g. "strlen()"...
> >> 
> >> Whether making it binary safe would be a major change or not is
> >> something I haven't researched yet but it seems like a change that
> >> should be generally useful upstream...
> >
> >I'd be OK with this, as discussed at FOSDEM, and I see you already
> >posted a ptach for this.
> 
> Yes. I take it you're pretty busy with the kdbus stuff right now but a
> review of those patches would be nice when you have the time.
> 


Lennart

-- 
Lennart Poettering, Red Hat

Message #71 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-bugs@zugschlus.de>

To: Mourad De Clerck <debian-bugs@aquazul.com>, 618862@bugs.debian.org, 618862-submitter@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Sun, 4 May 2014 23:33:27 +0200

severity #618862 important
thanks

On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all, and requires
> password input for every volume that wasn't activated already. Luckily, my
> root FS is activated by the initramfs.
> 
> I don't want to have to type in a password for every encrypted volume: on
> some of my machines this would mean having to type five or more passwords on
> boot.

I have a quite similar setup, only that the keys needed to unlock the
12 LVs are like 300 bytes of binary gibberish long. Typing them during
system boot is kind of out of the question.

Missing keyscript support is a total surprise to me, which breaks my
three most important systems. I am thus raising the severity of this
bug to important. It could also be higher, since it breaks the system.

I am also concerned since I remember well analyzing the scripts in the
initrd when I developed my cryptdisk setup. Since these mechanics seem
to have moved into systemd, I have learned that I would not have been
able to find out what's going on during system boot if we had systemd
back then. I don't like that idea at all.

Management Summary: Please make keyscript work.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062

Message #79 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: 618862@bugs.debian.org, 618862-submitter@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Sat, 19 Jul 2014 09:18:07 +0200

Version: 208-6

On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all, and requires
> password input for every volume that wasn't activated already. Luckily, my
> root FS is activated by the initramfs.

I have a slightly simplier setup: small /boot, big crypted partition, 
with LVM on it. root and swap are LVs. The only "interesting" part is 
the `passdev` keyscript from pkg:cryptsetup, which mounts a device and 
reads a file on that device as the actual key.

With the upgrade from 204-14 to 208-6, my system shows an interesting 
behaviour. The crypt is properly opened in initrd, but then systemd 
decides to reopen it, totally failing to use the keyscript and its 
"weird" keyfile naming, resulting in a timeout:

Jul 18 20:42:29 nana systemd[1]: Expecting device dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device...
Jul 18 20:43:59 nana systemd[1]: Job dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device/start timed out.
Jul 18 20:43:59 nana systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device.
Jul 18 20:43:59 nana systemd[1]: Dependency failed for Cryptography Setup for nana-crypt.
Jul 18 20:43:59 nana systemd[1]: Dependency failed for Encrypted Volumes.

My crypttab:
# <target name> <source device>         <key file>      <options>
nana-crypt      UUID=ffff....           /dev/disk/by-label/usbext3:/keyfile-nana.luks:10         luks,discard,keyscript=/lib/cryptsetup/scripts/passdev,tries=1

My fstab:
LABEL=nana-boot				/boot	ext4	noatime,discard				0	0
/dev/mapper/nana--vg01-nana--root	/	ext4	noatime,discard,errors=remount-ro	0	1
/dev/mapper/nana--vg01-nana--home	/home	ext4	noatime,discard,errors=remount-ro	0	1
/dev/mapper/nana--vg01-nana--swap	none	swap	defaults				0	0

Greets
Evgeni

Message #87 received at 618862@bugs.debian.org (full text, mbox, reply):

From: An Inbox <an.inbox@free.fr>

To: 618862@bugs.debian.org, 618862-submitter@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Sun, 27 Jul 2014 19:43:07 +0200

    Hi,

    I have the same issue as Evgeni above in a similar set-up and can 
provide a bit more information. It seems some alignment is needed 
between packages cryptsetup, initramfs-tools and systemd.

    In the cryptsetup documentation, there is a README on how to 
configure an encrypted root disk where the decryption key is read from 
another media file, see /usr/share/doc/cryptsetup/README.initramfs.gz 
section 10.
    The recommended approach is to use the passdev "script" (it's 
actually a binary, but makes use of the "keyscript" feature discussed 
here). This requires putting an entry in /etc/crypttab.
    As a good documentation reading user ;) this is what I did, and got 
a set-up like Evgeni. This used to work fine before I switched to 
systemd (on Jessie too), and now I have this same delay at boot.

    What happens is that the keyscript/passdev is correctly handled by 
the initramfs tools. They pick up the /etc/crypttab entry, puts 
everything required in the initramfs. And the encrypted root is 
successfully mounted and switched to by the initramfs.

    Then systemd is started from the root filesystem. Its cryptsetup 
generator processes the /etc/crypttab entries. It also processes the 
root entry, with its "keyscript" parameter, and generates under /run a 
service unit for it. Then systemd tries opening and mounting the LUKS 
device that is already opened and mounted, and get stuck until it times 
out. Then the boot proceeds successfully.

    It seems to me that systemd has the assumption that an encrypted 
root device is NOT described in /etc/crypttab. I may be wrong on this 
but when I look at documentation from Arch, which has migrated to 
systemd, the encrypted root is handled through kernel parameters handled 
in the initramfs and not through /etc/cryptab. See for example:
https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#Boot_loader

    This issue can be worked-arounded by using the (different from 
Arch) kernel parameters "cryptopts" in Debian too, and removing the root 
entry from /etc/crypttab. This is documented in README.initramfs.gz 
section 7, but the doc actually recommends against this and says it's 
better to use crypttab instead.

    Another work-around would be for the generated systemd 
configuration to be robust against an already opened/mounted device, in 
case the system or user does things in the initramfs already. Or to 
ignore the root fs in /etc/crypttab, as on principle it is already there 
when systemd is started from it.
    As a user I personally prefer having all my crypto partitions in 
one place under /etc/crypttab, rather than having to special case the 
root fs using kernel parameters. The root fs is a special case 
technically, but I'd rather have the infrastructure deal with this. I'm 
sure there will be othe opinions, in the end it's not a big deal as long 
as what's required is documented consistently across packages and 
existing configurations are migrated properly (if need be).

    In any case, the initial bug does not apply to me: the keyscript 
parameter is for the initramfs and cryptsetup, and they handle it just 
fine. If Mourad still follows the thread, could you try on a recent 
Jessie or Sid release? (the initial bug is old now). The fix could be 
just a documentation alignment, and/or having systemd ignoring the root 
fs entry in crypttab.

    All this under Jessie, with:
    - systemd 208-6
    - initramfs-tools 0.115
    - cryptsetup 2:1.6.4-4

    And by the way, thanks to all for the good work. The transition to 
systemd is rather smooth considering how big a change it is, and I like 
the result so far.

    Thanks!

Message #99 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Mikhail Morfikov <mmorfikov@gmail.com>

To: Debian Bug Tracking System <618862@bugs.debian.org>

Subject: Re: systemd: ignores keyscript in crypttab

Date: Thu, 15 Jan 2015 02:45:07 +0100

Source: systemd
Followup-For: Bug #618862

Is there a solution to this issue?

I'm currently using debian sid + sysvinit because I can't switch to systemd.

This is my setup:

root:~# lsblk -f
NAME                     FSTYPE      LABEL   UUID
MOUNTPOINT
sda
├─sda1                   ntfs        windows 36442BAC442B6E35
├─sda2                   ext4        boot    4c67dff5-3d8e-4b3f-
9cf1-49b88d5f67a9   /boot
├─sda3                   crypto_LUKS         9e03ae84-2f10-4f88-bf1c-
d7507ad30f78
│ └─debian_laptop        LVM2_member         1f7G9n-hwJ4-hD20-N9GP-3l77
-8tCi-uM7LZG
│   ├─debian_laptop-root ext4        root    dfdc8fb7-d9d4-4cd4-869c-
0f1910a3a17e   /
│   ├─debian_laptop-home ext4        home
27632431-fa15-49ba-8354-9c193e321aa6   /home
│   ├─debian_laptop-tmp  ext4        tmp     be5e9b14-4f41-462a-
b3c6-8502e88cc0c7
│   └─debian_laptop-swap swap                c4f58930-bfda-4f4e-
bad0-2be8d1b5bc9e
├─sda4
├─sda5                   crypto_LUKS         d314ed20-ffaf-
4a18-98a7-91538e79d981
│ └─grafi                ext4        grafi
990d110a-1310-4ab2-8a03-c952a408be11   /media/Grafi
└─sda6                   crypto_LUKS         f3c10054-0583-4e10-937b-
dcdc9a05a25c
  └─kabi                 ext4        kabi    b47e6dcd-924e-40fa-
a8b1-7593419f86d7   /media/Kabi

As you can see I have encrypted LVM, which works just fine. I have also two
other
encrypted volumes, and here's the problem. Take a look at /etc/crypttab
and /etc/fstab files:

root:~# egrep -v "^#" /etc/crypttab
debian_laptop   UUID=9e03ae84-2f10-4f88-bf1c-d7507ad30f78       none    luks
kabi            UUID=f3c10054-0583-4e10-937b-dcdc9a05a25c       debian_laptop
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
grafi           UUID=d314ed20-ffaf-4a18-98a7-91538e79d981       debian_laptop
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,noauto

root:~# egrep -v "^#" /etc/fstab

UUID=dfdc8fb7-d9d4-4cd4-869c-0f1910a3a17e       /
ext4    defaults,errors=remount-ro,commit=10    0 1
UUID=4c67dff5-3d8e-4b3f-9cf1-49b88d5f67a9       /boot                   ext4
defaults,errors=remount-ro,commit=10    0 2
UUID=27632431-fa15-49ba-8354-9c193e321aa6       /home                   ext4
defaults,errors=remount-ro,commit=10    0 2
UUID=990d110a-1310-4ab2-8a03-c952a408be11       /media/Grafi    ext4
defaults,nofail,errors=remount-ro,commit=10     0 2
UUID=b47e6dcd-924e-40fa-a8b1-7593419f86d7       /media/Kabi             ext4
defaults,errors=remount-ro,commit=10    0 2
UUID=c4f58930-bfda-4f4e-bad0-2be8d1b5bc9e       swap                    swap
defaults,pri=10         0 0

tmpfs /tmp tmpfs defaults,noatime,nosuid,noexec,nodev,mode=1777,size=512M 0 0

Both of the encrypted volumes use decrypt_derived script. I don't want to open
one
of them at boot time, that's why I used also the noauto option.

This setup works, but only with sysvinit. I've been using it for several
years and I've never had a problem with it.
So how can I fix this in order to switch to systemd?

Message #104 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Brainslug <brainslug@freakmail.de>

To: 618862@bugs.debian.org

Subject: Re: systemd: ignores keyscript in crypttab

Date: Mon, 30 Mar 2015 10:37:19 -0500

Hi,

	I'm also affected by this problem. Very simple setup, encrypted root
and swap via decrypt_derived so I can suspend to disk:

/etc/crypttab:
sda5_crypt UUID=2fa9feb8-b096-41f7-bf17-41399ccc8004 none luks
sda4_crypt UUID=6d3382e4-58fc-4f10-9346-276bbc127e78 sda5_crypt
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

In /var/log/syslog:

Mar 11 20:37:38 hercules systemd-cryptsetup[544]: Encountered unknown
/etc/crypttab option
'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.


Any progress on this? I would think this needs to be fixed before jessie
can be released, otherwise a lot of systems out there will break?


Thanks & Cheers!

Message #109 received at 618862@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Brainslug <brainslug@freakmail.de>, 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Mon, 30 Mar 2015 18:28:06 +0200

[Message part 1 (text/plain, inline)]

On Mar 30, Brainslug <brainslug@freakmail.de> wrote:

> Any progress on this? I would think this needs to be fixed before jessie
> can be released, otherwise a lot of systems out there will break?
While both we and the upstream maintainers believe that continuing to 
support this feature is a good idea, so far acceptable patches have not 
been contributed.
I doubt that such patches will magically appear in a few days, so it 
looks like that jessie will not support keyscripts.

I should add some code to preinst to abort the installation if the
keyscript directive is used in crypttab.

-- 
ciao,
Marco

[Message part 2 (application/pgp-signature, inline)]

Message #114 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Ivan Jager <aij+debian@mrph.org>

To: "Marco d'Itri" <md@linux.it>, 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Mon, 30 Mar 2015 12:39:00 -0500

On Mon, Mar 30, 2015 at 11:28 AM, Marco d'Itri <md@linux.it> wrote:
> I should add some code to preinst to abort the installation if the
> keyscript directive is used in crypttab.

Would that still leave the system in a broken state though? Is preinst
early enough to avoid breakage due to uninstalling other packages?

I guess leaving the system unbootable with warning is a bit better
than without warning, but still...

Out of curiosity, how difficult would it be to have systemd fall back
to using the cryptdisks init scripts if it detects options it doesn't
recognize? Or could it be easily modified to always use the
initscripts until the built in replacement is mature enough to replace
it?

I'm assuming this should be taken with a mountain of salt, but
http://www.freedesktop.org/wiki/Software/systemd/ claims, "systemd
supports SysV and LSB init scripts and works as a replacement for
sysvinit".


Ivan

Message #119 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ivan Jager <aij+debian@mrph.org>, 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Mon, 30 Mar 2015 22:41:34 +0200

[Message part 1 (text/plain, inline)]

Am 30.03.2015 um 19:39 schrieb Ivan Jager:
> On Mon, Mar 30, 2015 at 11:28 AM, Marco d'Itri <md@linux.it> wrote:
>> I should add some code to preinst to abort the installation if the
>> keyscript directive is used in crypttab.
> 
> Would that still leave the system in a broken state though? Is preinst
> early enough to avoid breakage due to uninstalling other packages?
> 
> I guess leaving the system unbootable with warning is a bit better
> than without warning, but still...

Keep in mind, that on upgrades, we retain the sysvinit binary, which you
can boot via the init=/lib/sysvinit/init kernel comman line parameter
for this very reason, i.e. systemd failing to boot your system.
Grub will even automatically create a boot menu for your (it's under
advanced settings)

So maybe, instead of aborting in preinst, we could simply show a warning
in pointing people at that possibility? And telling them, that they can
switch back fully via "apt-get install sysvinit-core".

> Out of curiosity, how difficult would it be to have systemd fall back
> to using the cryptdisks init scripts if it detects options it doesn't
> recognize? Or could it be easily modified to always use the
> initscripts until the built in replacement is mature enough to replace
> it?

I don't think this would work. Systemd's mount mechanisms are highly
dynamic and event based. That simply doesn't fit with how the cryptsetup
SysV init script works.

> I'm assuming this should be taken with a mountain of salt, but
> http://www.freedesktop.org/wiki/Software/systemd/ claims, "systemd
> supports SysV and LSB init scripts and works as a replacement for
> sysvinit".

For functionality, like cryptsetup, which integrates so deeply in the
boot process, you can't just use the old SysV init scripts, that's correct.

As a rough approximation, every SysV init script which runs in
/etc/rcS.d/ would should ideally be converted to integrate properly.

For SysV init scripts which run in runlevel 2-5, the backwards
compatibility is quite good.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #124 received at 618862@bugs.debian.org (full text, mbox, reply):

From: GW <gw.2015@tnode.com>

To: <618862@bugs.debian.org>

Subject: Re: systemd: ignores keyscript in crypttab

Date: Tue, 05 May 2015 13:38:40 +0100

[Message part 1 (text/plain, inline)]

  

Hello, 

In case someone else needs it, a workaround for the common
use case of using the `decrypt_derived` keyscript to unlock partitions
is to save the derived key into a file on the encrypted partition that
you would otherwise derive from (make sure only root can access it).
This at least works for the encrypted root partition on which others
depend on and is as secure as using the decrypt_derived keyscript.


http://gw.tnode.com/debian/issues-and-workarounds-for-debian-8/


Greetings,
 gw  

  

[Message part 2 (text/html, inline)]

Message #133 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Alberto Bertogli <albertito@blitiri.com.ar>

To: Lennart Poettering <lennart@poettering.net>

Cc: David Härdeman <david@hardeman.nu>, Michael Biebl <biebl@debian.org>, Harald Jenny <harald@a-little-linux-box.at>, systemd-devel@lists.freedesktop.org, 618862@bugs.debian.org

Subject: Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Mon, 25 May 2015 23:05:40 +0100

I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...


On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
> On Thu, 30.01.14 10:40, David Härdeman (david@hardeman.nu) wrote:
> 
> > a) getting the name of the cryptdev that the password request
> > corresponds to currently involves parsing the prompt message
> > ("Please enter passphrase for disk %s!") which is obviously not a
> > real solution...
> > 
> > This issue is fixable with minor upstream changes, e.g. by extending
> > the PasswordAgent protocol to add "Subsystem=cryptsetup" and
> > "Target=<diskname>" entries to the "ask.xxxx" file.
> 
> I'd be fine with adding a field "Id=" or so, which then is filled by an
> identifier of some kind be the cryptsetup tool that is useful to
> identify the device to query things on. for example:
> "Id=cryptsetup:/dev/sda5" or so could be one way how this could be
> filled in. We wouldn't enfoce any kind of syntax on this, just suggest
> some common sense so that people choose identifiers that are unlikely to
> clash with other subsystems, and somewhat reasonable to read...

... and I ran into a problem with this, because in practise this field
can look like:

  Id=cryptsetup:ST1234AB567-1CD234 (cbackups) on /var/backups/

for a crypttab line like:

  cbackups /dev/disk/by-id/ata-ST1234AB567-1CD234_1XY2ZWAB-part2 cbackups luks,keyscript=/usr/bin/kxc-cryptsetup


because it comes from the "name", which seems to be constructed for
human consumption, at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n596

So a password agent _still_ needs to resort to brittle parsing of the
"Id" field in order to find the corresponding crypttab entry.


Would changing get_password() to take an additional id, which would be
the volume name (argv[2]), and use that for the ask_password_auto() id,
be ok with you?

That would allow password agents to have a reliable id to work with
without doing brittle parsing, and matching what's in crypttab.


In theory, existing code should not need to adjust to the change, as the
proposed change is already a possibility when neither the mount point or
description are available, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n607
I don't know of any password agents to verify in practise, though.



> > b) the password agent implementation in systemd doesn't seem to
> > handle binary strings (i.e. strings with '\0'), as can be seen by
> > calls to e.g. "strlen()"...
> > 
> > Whether making it binary safe would be a major change or not is
> > something I haven't researched yet but it seems like a change that
> > should be generally useful upstream...
> 
> I'd be OK with this, as discussed at FOSDEM, and I see you already
> posted a ptach for this.

Has this been merged?

Is it safe for a password agent to write content with \0 back to the
socket?

Thanks!
		Alberto


[1]: In case it helps anyone else, I added the "initramfs" option to
crypttab as a workaround, which works in my case because the script
(kxc) is initramfs-ready.

Message #138 received at 618862@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Alberto Bertogli <albertito@blitiri.com.ar>

Cc: Lennart Poettering <lennart@poettering.net>, Michael Biebl <biebl@debian.org>, Harald Jenny <harald@a-little-linux-box.at>, systemd-devel@lists.freedesktop.org, 618862@bugs.debian.org

Subject: Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

Date: Tue, 26 May 2015 10:36:33 +0200

On 2015-05-26 00:05, Alberto Bertogli wrote:
> I hit this issue after upgrading a system that used keyscript to 
> Jessie,
> and it would no longer boot with systemd [1].
> 
> That led me to look into adding a password agent for my use case, 
> and/or
> creating a generic one that would invoke keyscripts as a workaround...
> 
> 
...
> On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
>> On Thu, 30.01.14 10:40, David Härdeman (david@hardeman.nu) wrote:
>> > b) the password agent implementation in systemd doesn't seem to
>> > handle binary strings (i.e. strings with '\0'), as can be seen by
>> > calls to e.g. "strlen()"...
>> >
>> > Whether making it binary safe would be a major change or not is
>> > something I haven't researched yet but it seems like a change that
>> > should be generally useful upstream...
>> 
>> I'd be OK with this, as discussed at FOSDEM, and I see you already
>> posted a ptach for this.
> 
> Has this been merged?

No, the last word was basically this thread:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021246.html

I don't have the time to implement a "complete" solution...

> Is it safe for a password agent to write content with \0 back to the
> socket?

Haven't checked but I'd be surprised if that was the case.

//David

Message #139 received at 756202-done@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Evangelos Skarmoutsos <skarmoutsosv@gmail.com>, 756202-done@bugs.debian.org

Subject: Re: Bug#756202: systemd: Slow bootup (more than 3 minutes), comment swap line in fstab

Date: Thu, 27 Aug 2015 10:14:01 +0200

Hello,

this is a desired change and won't be relaxed again. Ignoring fstab entries has
led to too many bugs.

See
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#systemd-auto-mounts-incompat

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #144 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 786393@bugs.debian.org, 618862@bugs.debian.org

Subject: Re: Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround

Date: Thu, 27 Aug 2015 10:28:09 +0200

[Message part 1 (text/plain, inline)]

unmerge 756202
reopen 786393
reopen 618862
thanks

Meh, #756202 is something entirely different than #786393 and #618862.
Unmerging and reopening the latter two.

Sorry for the noise!

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[signature.asc (application/pgp-signature, inline)]

Message #153 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Martin Pitt <mpitt@debian.org>, 618862@bugs.debian.org

Subject: Re: Bug#618862: Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround

Date: Thu, 27 Aug 2015 11:44:46 +0200

[Message part 1 (text/plain, inline)]

Am 27.08.2015 um 10:28 schrieb Martin Pitt:
> unmerge 756202
> reopen 786393
> reopen 618862
> thanks
> 
> Meh, #756202 is something entirely different than #786393 and #618862.

Yes and no.
At least the bug report in [1] has
cryptswap UUID=xxxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxdc3 sda4_crypt
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap
in his crypttab. So it's the same keyscript issue.

But yeah, for the original bug reporter it might actually just be a
broken UUID for the swap line in /etc/fstab.


Michael



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756202#10
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #158 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Marcello Barnaba <vjt@openssl.it>

To: 618862@bugs.debian.org

Subject: Re: systemd: ignores keyscript in crypttab

Date: Fri, 16 Oct 2015 12:02:46 +0200

> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all

I confirm the same problem albeit while using the passdev keyscript.

Workaround: add "luks=no" to the kernel command line to disable systemd's generator: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html

Debian Jessie *supports* keyscripts, as long as faulty software is disabled.

~Marcello
-- 
~ vjt@openssl.it
~ http://sindro.me/

Message #163 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Rick Thomas <rbthomas@pobox.com>

To: Marcello Barnaba <vjt@openssl.it>, 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Fri, 16 Oct 2015 08:40:16 -0700

On Oct 16, 2015, at 3:02 AM, Marcello Barnaba <vjt@openssl.it> wrote:

>> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
>> my root and swap partition are encrypted with cryptsetup; root uses a custom
>> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
>> systemd seems to be unable to work with keyscripts at all
> 
> I confirm the same problem albeit while using the passdev keyscript.
> 
> Workaround: add "luks=no" to the kernel command line to disable systemd's generator: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> 
> Debian Jessie *supports* keyscripts, as long as faulty software is disabled.
> 
> ~Marcello

Marcello,

Does this work for encrypted root as well?  Or is it only for things like swap and /home that can wait until after switching out of initramdisk?
If it works for encrypted root, this is genuinely good news!


Thanks!
Rick

Message #168 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Marcello Barnaba <vjt@openssl.it>

To: 618862@bugs.debian.org

Cc: Rick Thomas <rbthomas@pobox.com>

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Fri, 16 Oct 2015 18:20:01 +0200

>> Workaround: add "luks=no" to the kernel command line to disable systemd's generator: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html

> Does this work for encrypted root as well?  Or is it only for things like swap and /home that can wait until after switching out of initramdisk?
> If it works for encrypted root, this is genuinely good news!

Yes. I'm using passdev in initramfs at the scripts/local-top
stage as per cryptsetup docs to mount an encrypted root,
unlocking it via a keyfile located on an USB key.

/etc/crypttab:

  # dev source keyfile opts
  root /dev/sda2 /dev/disk/by-label/keys:/rootkey luks,keyscript=passdev

Then, update-initramfs -u

/dev/sda2 set up using cryptsetup luksFormat. No LVM.
Working on current Kali Linux, based on Jessie/sid.
Sorry I don't have version numbers at hand.

HTH, YMMV! :)

~Marcello
-- 
~ vjt@openssl.it
~ http://sindro.me/

Message #173 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Rick Thomas <rbthomas@pobox.com>

To: Marcello Barnaba <vjt@openssl.it>, 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Fri, 16 Oct 2015 09:28:54 -0700

On Oct 16, 2015, at 9:20 AM, Marcello Barnaba <vjt@openssl.it> wrote:

> 
>>> Workaround: add "luks=no" to the kernel command line to disable systemd's generator: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
> 
>> Does this work for encrypted root as well?  Or is it only for things like swap and /home that can wait until after switching out of initramdisk?
>> If it works for encrypted root, this is genuinely good news!
> 
> Yes. I'm using passdev in initramfs at the scripts/local-top
> stage as per cryptsetup docs to mount an encrypted root,
> unlocking it via a keyfile located on an USB key.
> 
> /etc/crypttab:
> 
>  # dev source keyfile opts
>  root /dev/sda2 /dev/disk/by-label/keys:/rootkey luks,keyscript=passdev
> 
> Then, update-initramfs -u
> 
> /dev/sda2 set up using cryptsetup luksFormat. No LVM.
> Working on current Kali Linux, based on Jessie/sid.
> Sorry I don't have version numbers at hand.
> 
> HTH, YMMV! :)
> 
> ~Marcello

Woo Hoo!  I can’t wait to test it!  (-: (-: (-:

Message #178 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Rick Thomas <rbthomas@pobox.com>, 618862@bugs.debian.org

Cc: Marcello Barnaba <vjt@openssl.it>

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Sun, 18 Oct 2015 13:04:44 +0200

Rick Thomas [2015-10-16  8:40 -0700]:
> Does this work for encrypted root as well?

FTR, systemd isn't involved in unlocking the root file system, that
already (has to) happen in the initramfs. So this can only affect
non-root file systems.

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #183 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Marcello Barnaba <vjt@openssl.it>

To: 618862@bugs.debian.org

Cc: Rick Thomas <rbthomas@pobox.com>, Martin Pitt <mpitt@debian.org>

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Sun, 18 Oct 2015 13:17:56 +0200

>> Does this work for encrypted root as well?

> FTR, systemd isn't involved in unlocking the root file system, that
> already (has to) happen in the initramfs. So this can only affect
> non-root file systems.

With the setup I've detailed above (encrypted LUKS root
unlocked via the passdev keyscript) I see autogenerated
systemd units trying to setup an *already mounted root*.
Same for encrypted swap, already set up in initramfs.

The units wait and time out after 90 seconds, causing a
noticeable boot delay. Adding "luks=no" (or rd.luks=no)
disables the generator and the delay.

If you need more details or information other than what I've
provided above please let me know.

Thanks,

~Marcello
-- 
~ vjt@openssl.it
~ http://sindro.me/

Message #188 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Rick Thomas <rbthomas@pobox.com>

To: 618862@bugs.debian.org

Cc: Martin Pitt <mpitt@debian.org>, Marcello Barnaba <vjt@openssl.it>

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Sat, 24 Oct 2015 04:06:49 -0700

I tested Marcello’s workaround.  It works!  That’s wonderful!  Thank you so much, Marcello!

Now some further thoughts on the subject…

It’s a workaround for this bug, but, unfortunately it’s just a workaround not a real fix.  In particular, using a “luks=no” kernel command line option disables all luks encryption that is not unlocked in the initrd phase.  Decryption that waits until we’re out of the initrd is a less common use-case, but nevertheless a legitimate one.

A better work around would be to recognize the (documented but not currently working under systemd) crypttab option “noearly” — which prevents attempts to decrypt when in initrd — and a new (not currently documented or implemented) option “earlyonly” — which specifies that decryption for this item must occur while in initrd and should not be attempted outside of initrd.

But even that’s just a workaround.  A true _fix_ would be to never attempt to decrypt any item has already been successfully decrypted by an earlier stage.

Enjoy!
Rick

 
On Oct 18, 2015, at 4:17 AM, Marcello Barnaba <vjt@openssl.it> wrote:

> 
>>> Does this work for encrypted root as well?
> 
>> FTR, systemd isn't involved in unlocking the root file system, that
>> already (has to) happen in the initramfs. So this can only affect
>> non-root file systems.
> 
> With the setup I've detailed above (encrypted LUKS root
> unlocked via the passdev keyscript) I see autogenerated
> systemd units trying to setup an *already mounted root*.
> Same for encrypted swap, already set up in initramfs.
> 
> The units wait and time out after 90 seconds, causing a
> noticeable boot delay. Adding "luks=no" (or rd.luks=no)
> disables the generator and the delay.
> 
> If you need more details or information other than what I've
> provided above please let me know.
> 
> Thanks,
> 
> ~Marcello
> -- 
> ~ vjt@openssl.it
> ~ http://sindro.me/
> 
> -- 
> To unsubscribe, send mail to 618862-unsubscribe@bugs.debian.org.
> 

Message #197 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Avi Deitcher <avi@deitcher.net>

To: Marcello Barnaba <vjt@openssl.it>

Cc: Rick Thomas <rbthomas@pobox.com>, Martin Pitt <mpitt@debian.org>, 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Tue, 12 Apr 2016 14:27:09 +0300

[Message part 1 (text/plain, inline)]

 > Workaround: add "luks=no" to the kernel command line to disable
systemd's generator

This worked great... until you try to add another partition to crypttab.
Since the cryptroot in initrd only does root, but luks=no disables all
others.


E.g. if crypttab looks like

root /dev/sda1 /dev/sda5:/keyfile rootdev,keyscript=/path/to/some/keyscript
swap /dev/sda2 /dev/urandom swap

then you are stuck:

1. luks=no: systemd doesn't try to reopen /dev/sda1 (GOOD), but it also
doesn't try to enable swap (BAD)
2. comment out root from crypttab: systemd doesn't try to reopen /dev/sda1
(GOOD), but it then needs a mess of kernel command-line options in grub.cfg
(BAD), and it doesn't install the necessary binaries to initramfs (BAD).

Is there any clean solution that recognizes the granularity? Maybe one way
is to put all encrypted filesystems loaded via initramfs?



-- 
Avi Deitcher
avi@deitcher.net
Follow me http://twitter.com/avideitcher
Read me http://blog.atomicinc.com

[Message part 2 (text/html, inline)]

Message #202 received at 618862@bugs.debian.org (full text, mbox, reply):

From: guenther kuenzel <mog+debian.org@guuk.eu>

To: 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Tue, 12 Apr 2016 17:18:46 +0200

the only clean solution that i have found so far. put the encryption on
the blockdevice and use LVM for partitioning. if you have multiple
disks, use software raid, encryption on the raid blockdevice and LVM for
partitioning. that is only a workaround which prevents the requirement
to define multiple devices in crypttab, but still being able to encrypt
multiple volumes.

cryptsetup with keyscript and multiple encrypted devices does not work
for me.

greetings

Message #207 received at 618862@bugs.debian.org (full text, mbox, reply):

From: guenther kuenzel <mog+debian.org@guuk.eu>

To: 618862@bugs.debian.org

Subject: Re: Bug#618862: systemd: ignores keyscript in crypttab

Date: Tue, 12 Apr 2016 17:40:42 +0200

maybe i should have given more details about my suggested solution.


create your partitions as usual, but create one partition big enough to
store all your encrypted data:

/dev/sda1 -> /boot
/dev/sda2 -> all encrypted data
...

encrypt the desired partition:

cryptsetup ... create encrypted-sda2 /dev/sda2

put LVM on the encrypted device:

pvcreate ... /dev/mapper/encrypted-sda2
vgcreate ... encrypted-volume /dev/mapper/encrypted-sda2

create your logical volumes for your encrypted needs:

lvcreate ... --name encrypted-root encrypted-volume
lvcreate ... --name encrypted-swap encrypted-volume

now you are able to add a single entry into crypttab while having
multiple logical volumes encrypted

Message #212 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Tobias Frost <tobi@debian.org>

To: Debian Bug Tracking System <618862@bugs.debian.org>

Subject: Re: systemd: ignores keyscript in crypttab

Date: Thu, 07 Jul 2016 16:13:20 +0200

[Message part 1 (text/plain, inline)]

Package: systemd
Followup-For: Bug #618862

Hallo,

I've just run into this during the dracut BoF at DebConf16, where we treid to
install dracut. So we were wondering if there is any progress / plans on this
issue?

Thanks!

-- 
tobi

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.114
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10-4
ii  libaudit1       1:2.5.2-1
ii  libblkid1       2.28-5
ii  libc6           2.22-11
ii  libcap2         1:2.25-1
ii  libcap2-bin     1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20     1.7.1-2
ii  libgpg-error0   1.23-1
ii  libidn11        1.32-3.1
ii  libkmod2        22-1.1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.28-5
ii  libpam0g        1.1.8-3.3
ii  libseccomp2     2.3.1-2
ii  libselinux1     2.5-3
ii  libsystemd0     230-5
ii  mount           2.28-5
ii  util-linux      2.28-5

Versions of packages systemd recommends:
ii  dbus            1.10.8-1
ii  libpam-systemd  230-5

Versions of packages systemd suggests:
ii  policykit-1        0.105-15
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  230-2

-- no debconf information

[systemd-delta.txt (text/plain, attachment)]

[systemd-analyze-dump.txt (text/plain, attachment)]

[dsh-enabled.txt (text/plain, attachment)]

[fstab (text/plain, attachment)]

Message #219 received at 618862@bugs.debian.org (full text, mbox, reply):

From: Bruno Bierbaumer <list@bierbaumer.net>

To: Debian Bug Tracking System <618862@bugs.debian.org>

Subject: Re: systemd: ignores keyscript in crypttab

Date: Wed, 07 Sep 2016 20:38:34 +0200

Package: systemd
Version: 231-4
Followup-For: Bug #618862

Hello,
I also run into this issue while trying to mount 2 disks (LUKS + VeraCrypt) encrypted with the same passphrase during boot.
Is there any progress on this bug?

Greetings,
Bruno

-- Package-specific info:


*** reportbug-systemd-20160907-1006-qZ2Gk_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Bruno Bierbaumer <list@bierbaumer.net>
To: Debian Bug Tracking System <618862@bugs.debian.org>
Subject: Re: systemd: ignores keyscript in crypttab
Message-ID: <147327319493.1006.14100880853937122454.reportbug@pc.lan>
X-Mailer: reportbug 6.6.6
Date: Wed, 07 Sep 2016 20:33:14 +0200

Package: systemd
Version: 231-4
Followup-For: Bug #618862

Hello,
I also run into this issue while trying to mount 2 disks (LUKS + VeraCrypt) with the same passphrase during boot.
Is there any progress on this bug?

Greetings,
Bruno


-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.115
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10.95-4
ii  libaudit1       1:2.6.6-1
ii  libblkid1       2.28.1-1
ii  libc6           2.23-5
ii  libcap2         1:2.25-1
ii  libcap2-bin     1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20     1.7.3-1
ii  libgpg-error0   1.24-1
ii  libidn11        1.33-1
ii  libkmod2        22-1.1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.28.1-1
ii  libpam0g        1.1.8-3.3
ii  libseccomp2     2.3.1-2
ii  libselinux1     2.5-3
ii  libsystemd0     231-4
ii  mount           2.28.1-1
ii  util-linux      2.28.1-1

Versions of packages systemd recommends:
ii  dbus            1.10.10-1
ii  libpam-systemd  231-4

Versions of packages systemd suggests:
ii  policykit-1        0.105-16
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  231-4

-- no debconf information


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.115
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10.95-4
ii  libaudit1       1:2.6.6-1
ii  libblkid1       2.28.1-1
ii  libc6           2.23-5
ii  libcap2         1:2.25-1
ii  libcap2-bin     1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20     1.7.3-1
ii  libgpg-error0   1.24-1
ii  libidn11        1.33-1
ii  libkmod2        22-1.1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.28.1-1
ii  libpam0g        1.1.8-3.3
ii  libseccomp2     2.3.1-2
ii  libselinux1     2.5-3
ii  libsystemd0     231-4
ii  mount           2.28.1-1
ii  util-linux      2.28.1-1

Versions of packages systemd recommends:
ii  dbus            1.10.10-1
ii  libpam-systemd  231-4

Versions of packages systemd suggests:
ii  policykit-1        0.105-16
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  231-4

-- no debconf information

Message #226 received at 618862@bugs.debian.org (full text, mbox, reply):

From: greatcanadian@TheGreatCanadianMale.com

To: 618862@bugs.debian.org

Subject: Please recheck your delivery address (UPS parcel 8987275)

Date: Sun, 26 Feb 2017 20:32:27 -0700

[Message part 1 (text/plain, inline)]

Dear Customer,

Your parcel was successfully delivered February 23 to UPS Station, but our courier cound not contact you.

Postal label is enclosed to this e-mail. Please check the attachment!

With thanks and appreciation,
Frank Frost,
UPS Mail Delivery Agent.

[UPS-Label-8987275.zip (application/zip, attachment)]

Send a report that this bug log contains spam.