Re: [lmi] `openssl passwd` not appearing with 'set -vx'

[Vadim Zeitlin]

On Tue, 5 May 2020 23:59:43 +0000 Greg Chicares <address@hidden> wrote:

GC> Today I ran 'install_centos.sh' and compared its output to yesterday's,
GC> and this seemed odd:
GC> 
GC>  getent group "greg" || groupadd --gid="1000" "greg"
GC>  + getent group greg
GC>  + groupadd --gid=1000 greg
GC> -getent passwd "greg" || useradd   --gid="1000"   --uid="1000"   
--create-home   --shell=/bin/zsh   
--password="$1$irXaygJk$/bPP/s2keK3ch23UrfXmf/"   "greg"
GC> +getent passwd "greg" || useradd   --gid="1000"   --uid="1000"   
--create-home   --shell=/bin/zsh   
--password="$1$HjRcinT1$zVMljzLGLRDenLwa7OUgP0"   "greg"
GC>  + getent passwd greg
GC> -+ useradd --gid=1000 --uid=1000 --create-home --shell=/bin/zsh 
'--password=$/bPP/s2keK3ch23UrfXmf/' greg
GC> ++ useradd --gid=1000 --uid=1000 --create-home --shell=/bin/zsh --password= 
greg
GC> 
GC> Both yesterday's (-) and today's (+) 'getent ... || useradd ...' commands
GC> give nonempty random passwords, but on the last pair of quoted lines,
GC> yesterday's has a single-quoted
GC>   '--password=$/bPP/s2keK3ch23UrfXmf/' greg
GC> whereas today's has a non-quoted, empty
GC>   --password= greg
GC> which is what seems odd to me.

 I don't know what does it tell about me (nothing good probably), but this
doesn't seem odd to me. In the latter case the password string _clearly_
contains 3 shell variables: "1", "HjRcinT1" and "zVMljzLGLRDenLwa7OUgP0".
Unsurprisingly, you don't have any variables with such names, so expanding
them results in an empty string (this wouldn't be the case for "$1" if you
passed any parameters to your script).

 In the former case, there were 2 variables: "1" and "irXaygJk", followed
by a string, because "/" is not allowed in shell identifiers and so can't
be part of a variable. So the rest of the string remained.


 So this is the explanation, but I guess you're also interested in a fix or
at least a workaround for the problem of having differences in the output
between runs. Unfortunately I don't have any particularly good news, as
there doesn't seem to be any simple case to perform expansion in the
script, but not in the tracing output. The obvious solution would be to use
"set +x" to turn off tracing for this particular line. Another one would be
to put it in a subshell and then filter tracing output in some way.
Finally, there is also a hack with passing some special salt value to
openssl to make it generate a password which doesn't change after
expansion, so, even if it still expands, it would at least expand in the
same way every time (assuming you don't have the habit of naming your
variables "HjRcinT1" etc). I don't know if it's acceptable to reuse the
same password, but if it is, this looks like the simplest solution.


GC> We've previously seen odd splitting of "+" lines with 'dash -x':
GC>   https://lists.nongnu.org/archive/html/lmi/2019-04/msg00050.html
GC> This script is executed in a chroot where:
GC>   $cat /etc/centos-release 
GC>   CentOS Linux release 7.8.2003 (Core)
GC>   $ls -l /usr/bin/sh      
GC>   lrwxrwxrwx 1 root root 4 May  5 20:42 /usr/bin/sh -> bash
GC> so might the above surprise be a similarly random 'bash -x' artifact?

 The only potentially surprising thing here is that bash expands variables
in trace output. I admit I wasn't totally sure about this myself, but a
quick test shows that this is clearly the case:

        % foo=bar bash -xc 'echo "$foo"'
        + echo bar
        bar

And this behaviour is consistent across all the shells I tried, so even
though I'm too lazy to check this in POSIX, I'm pretty sure it's
intentional and "-x" output is supposed to expand the commands before
echoing them.

GC> Is there something about today's password
GC>   $/bPP/s2keK3ch23UrfXmf/
GC> generated by this particular invocation of 'openssl' that causes
GC> misbehavior when yesterday's
GC>   $1$irXaygJk$/bPP/s2keK3ch23UrfXmf/
GC> seemed to work? Aligning them both this way:
GC>              $/bPP/s2keK3ch23UrfXmf/
GC>   $1$irXaygJk$/bPP/s2keK3ch23UrfXmf/
GC> shows that the last 23 characters match, yet in yesterday's
GC> case where a non-empty string was passed:
GC>   -+ useradd [...] '--password=$/bPP/s2keK3ch23UrfXmf/' greg
GC> it looks like only those 23 were passed. But the behavior
GC> doesn't seem to be invariant, except for the initial "$1":
GC>   for z in 1 2 3 4 5; do openssl passwd -1 expired; done
GC>   $1$g4yg78K2$quQQfkwJHMcxJM7pmvgir.
GC>   $1$Zz/YeWiv$Fs8orLrKOMTHIubxnLd2Q.
GC>   $1$BkXQcVgK$93lkl6YrqJJU2IPIHQ5/N/
GC>   $1$ty0ET9aZ$QwiXRlGY0SgszAsAdU7Dz.
GC>   $1$GX7Y2dO8$tTEeIUjj14QhdsOogzniC1
GC> That 23 characters match seems so weird that I feel compelled
GC> to double-check it--indeed, they occur in two logs generated
GC> a day apart, but in none of the other dozens of logs I've saved:
GC>   grep -r s2keK centos*
GC>   centos_log_20200504T2251Z:getent passwd "greg" || useradd   --gid="1000"  
 --uid="1000"   --create-home   --shell=/bin/zsh   
--password="$1$irXaygJk$/bPP/s2keK3ch23UrfXmf/"   "greg"
GC>   centos_log_20200504T2251Z:+ useradd --gid=1000 --uid=1000 --create-home 
--shell=/bin/zsh '--password=$/bPP/s2keK3ch23UrfXmf/' greg
GC> The more I dig into this, the more puzzled I grow.

 I can't explain how did the 2 passwords manage to have identical tails.
This is indeed surprising and potentially bothersome, as it would seem that
the VM doesn't have enough entropy in it or there is some other weirdness
going on. I wouldn't use it for generating any private keys...

 Regards,
VZ

pgphLmWzRujdl.pgp
Description: PGP signature