Bug 254966 - geli setkey not working with detached provider
Summary: geli setkey not working with detached provider
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.2-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-geom (Nobody)
Depends on:
Reported: 2021-04-10 22:58 UTC by rob2g2
Modified: 2021-05-08 20:49 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description rob2g2 2021-04-10 22:58:37 UTC
trying to run "geli setkey -n 1 gpt/hd01" on a detached geli provider asks me for the master password, and after entering the right password just prints "Note, that the master key encrypted with old keys and/or passphrase may still exists in a metadata backup file." - so it does not ask me for the userpassword I want to set to slot 1 (as one woud expect). So either the man page should be changed to inform the user that setkey only works with attached providers or the program should be adapted so that after entering the right master password the user is asked for the user password. (IIRC this has already worked the last time - quite some time ago - when I used it)

"geli setkey -n 1 gpt/hd01" works when the provider is already attached - the dialogue:

Enter new passphrase: 
Reenter new passphrase: 
Note, that the master key encrypted with old keys and/or passphrase may still exists in a metadata backup file.

System: FreeBSD mach2020 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC  amd64
Comment 1 rob2g2 2021-04-10 23:18:43 UTC
same behaviour on 13.0-RC5
Comment 2 Michael Büker 2021-05-08 20:49:15 UTC
I can confirm this bug. It exists in 12.2-RELEASE-p6 and 13.0-RELEASE, but _not_ in 11.4-RELEASE-p9.

Steps to reproduce:

# mdconfig -a -t malloc -s 10M -u md10
# echo aaa | geli init -J - md10
# echo aaa | geli attach -j - md10
# geli status md10.eli
# geli detach md10

At this point, md10 is a geli volume with passphrase "aaa". Now, observe the failure of geli setkey:

# geli setkey -n0 md10

This command asks for the existing passphrase and then does nothing. It _should_ ask for the new passphrase (and correctly does so on 11.4-RELEASE).

The same happens when using passfiles:

# echo aaa > oldkey
# echo bbb > newkey
# geli setkey -n0 -j oldkey -J newkey md10

At this point, "aaa" is still the passphrase in slot 1 of md10.eli, even though it should be "bbb". Confirm this by:

# geli attach -j newkey md10

... which fails, and:

# geli attach -j oldkey md10

... which succeeds (but shouldn't).

Note that all is well when using geli setkey on md10.eli when it is attached. This bug only affect unattached volumes.