On Mon, 23 Jul 2018 at 18:32:44 +0200, Guilhem Moulin wrote:
> * /scripts/local-top/clevis: some bits look quite brittle, for
> instance
>
> psinfo=$(ps) # Doing this so I don't end up matching myself
> echo "$psinfo" | awk "/$cryptkeyscript/ { print \$1 }" | \
>
> and
>
> local $(grep '^CRYPTTAB_SOURCE=' /proc/$pid/environ)Oh, I see these have been addressed in https://github.com/latchset/clevis/pull/18#issuecomment-364683203 . The reason why cryptsetup's cryptroot-unlock doesn't use pidof(1) is because busybox's implementation doesn't support full pathnames, and since we don't own the namespace there is nothing preventing another package from running a program with that name. And replacing NUL bytes with linefeeds in the environment will lead to unexpected behavior if there are other variables set to a value containing a linefeed, for instance if your crypttab(5)'s 4th column contains an option set to value “blah\012CRYPTTAB_SOURCE=blah”. (Yes, doing so is asking for trouble, but…) So the following still holds: > I believe that cryptroot-unlock's approach [0] is a lot more robust. However I don't mean to dilute the main point of my former message: | that code uses undocumented bits, which […] MUST NOT be used outside | of src:cryptsetup. […] We have a documented interface for using the | output of a program as key or passphrase, and clevis should use that | instead of clevisloop(). -- Guilhem.
signature.asc
Description: PGP signature
