Skip to content
Snippets Groups Projects
Commit d6c6947b authored by Simon McVittie's avatar Simon McVittie
Browse files

d/tests: Avoid autopkgtest failure if test user has blank password

If the test user has a blank password (which might be the case in an
expendable test VM) and PAM accepts blank passwords, then
gdm-smartcard-sssd-or-password will always authenticate successfully.
If that's the case, temporarily change the user's password to be
non-empty while running our tests. Also do the same for root.
parent 87a20e43
Branches
Tags
No related merge requests found
......@@ -9,10 +9,12 @@ Depends: bash,
gnutls-bin,
openssl,
pamtester,
passwd,
softhsm2,
sssd,
util-linux
Restrictions: isolation-container,
Restrictions: breaks-testbed,
isolation-container,
needs-sudo,
allow-stderr
......@@ -84,7 +84,7 @@ function backup_file() {
[ ! -e "$back_path" ] || return 1
mkdir -p "$back_dir" || return 1
mv "$1" "$back_path" || return 1
cp -a "$1" "$back_path" || return 1
restore_paths+=("$back_path")
else
......@@ -128,7 +128,22 @@ bash "$tester"
find "$tmpdir" -type d -exec chmod 777 {} \;
find "$tmpdir" -type f -exec chmod 666 {} \;
backup_file /etc/passwd
backup_file /etc/shadow
# Ensure that the test user has a non-trivial password. If it had a blank
# password, then /etc/pam.d/gdm-smartcard-sssd-or-password would always
# authenticate successfully
  • Maintainer

    Mh, this could only happen in the very unlikely case in which the user password matches the provided PIN, no (which we could also make it random)?

    As we always pass such value to stdin, so in case the password should still be prompted no? And sending to it a wrong one it would still fail (that was my theory at least).

  • Author Maintainer

    If your password is blank (as in user::1000:... in /etc/passwd), then you're usually not even prompted, password authentication just succeeds. I think the transaction goes something like this:

    • authenticator: What's your PIN?
    • test script: wrong123456
    • authenticator: No, that's wrong.
    • (authenticator would normally show a password prompt here, but because the password is blank, it doesn't)
    • (authentication succeeds because the password is blank)

    I had this failure mode on the autopkgtest VM that I use to test my uploads, which has blank passwords (I prefer to use a blank password on expendable VMs, in preference to a well-known password that offers a false sense of security).

    Edited by Simon McVittie
  • Please register or sign in to reply
if pamtester -v gdm-password "$SUDO_USER" authenticate; then
( echo -n "$SUDO_USER:"; cat /proc/sys/kernel/random/uuid ) | chpasswd
fi
# Same, but for root
if pamtester -v gdm-password root authenticate; then
  • Maintainer

    @smcv This is not fully valid, because if root passes it's an error even if the password is unset.

    So actually we should try to use a password-less root, or pass it to the tester to ensure that root is never ever authenticated. That's because we're explicitly using auth [success=ok user_unknown=ignore default=bad] pam_succeed_if.so user != root quiet_success, so that's something we don't want to happen.

    Plus sssd does a further check on that.

  • Author Maintainer

    OK, I'll try that locally. I think it's probably best to let this migrate before we poke it again, though.

  • Please register or sign in to reply
( echo -n "root:"; cat /proc/sys/kernel/random/uuid ) | chpasswd
fi
backup_file /etc/sssd/sssd.conf
rm -f /etc/sssd/sssd.conf
user_home="$(runuser -u "$SUDO_USER" -- sh -c 'echo ~')"
mkdir -p "$user_home"
......@@ -152,6 +167,7 @@ for path_pair in "${softhsm2_conf_paths[@]}"; do
IFS=":" read -r -a path <<< "${path_pair}"
path="${path[1]}"
backup_file "$path"
rm -f "$path"
done
function test_authentication() {
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment