lock passwd implemented wrong on FreeBSD

Bug #1854594 reported by Igor Galić on 2019-11-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Igor Galić

Bug Description

(changing bug description after triage)

on FreeBSD, lock_passwd is implemented as `pw usermod <user> -h -`

This does not lock the account. It prompts for a password change on the console during cloud-init run.

To lock an account, we have to execute: `pw lock <name>`.

Igor Galić (i.galic) on 2019-11-30
tags: added: freebsd
description: updated
Igor Galić (i.galic) wrote :

i think i misinterpreted the failure here…
I got a password prompt for root, and assumed it came from a `passwd -l root` call, but the same could be easily true of the equally wrong implementation we have here:

    def lock_passwd(self, name):
        try:
            util.subp(['pw', 'usermod', name, '-h', '-'])
        except Exception as e:
            util.logexc(LOG, "Failed to lock user %s", name)
            raise e

this means, modify this user, read input from the FD supplied after -h, in this case, stdin.

Igor Galić (i.galic) wrote :

okay, so, here's the log output from (re-)running cloud-init clean --logs --reboot:

2019-12-04 10:25:32,678 - handlers.py[DEBUG]: start: init-network/config-users-groups: running config-users-groups with frequency once-per-instance
2019-12-04 10:25:32,678 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/3623889/sem/config_users_groups - wb: [644] 26 bytes
2019-12-04 10:25:32,680 - helpers.py[DEBUG]: Running config-users-groups using lock (<FileLock using file '/var/lib/cloud/instances/3623889/sem/config_users_gr
oups'>)
2019-12-04 10:25:32,681 - __init__.py[INFO]: User root already exists, skipping.
2019-12-04 10:25:32,682 - util.py[DEBUG]: Running command ['passwd', '-l', 'root'] with allowed return codes [0] (shell=False, capture=True)

That means, despite a (wrong) definition of lock_passwd in distros/freebsd.py, we're somehow calling the one for Linux…
Which seems unlikely, given the callpath:

cc_user_groups.py:handle() → cloud.distro.create_users()

$distro.py:add_user() → util.py:is_user() → pwd.is_user() # this is patform independent
$distro.py:lock_passwd() → where are we now?

I wonder if this has anything to do with Hetzner's vendor-data:

system_info:
    default_user:
        lock_passwd: true
        name: root
        shell: /bin/bash
    distro: ubuntu

it seems pretty ridiculous that the system_info can override the system's reality, but i guess sometimes this is necessary…

Scott Moser (smoser) wrote :

"it seems pretty ridiculous that the system_info can override the system's reality, but i guess sometimes this is necessary…"

Yeah... feel free to fix.

Changed in cloud-init:
status: New → Triaged
importance: Undecided → Medium
Igor Galić (i.galic) wrote :

i should create a separate bug for the bug i discovered while triaging this one

Igor Galić (i.galic) on 2019-12-04
summary: - lock passwd doesn't work on non-GNU passwd
+ lock passwd implemented wrong on FreeBSD
description: updated
Igor Galić (i.galic) wrote :
Changed in cloud-init:
assignee: nobody → Igor Galić (i.galic)
status: Triaged → In Progress
Igor Galić (i.galic) wrote :

committed in e2840f1771158748780a768f6bfbb117cd7610c6

Changed in cloud-init:
status: In Progress → Fix Committed
Igor Galić (i.galic) wrote :

> this means, modify this user, read input from the FD supplied after -h, in this case, stdin.

no, it doesn't.

it really does mean that *this* bug: https://bugs.launchpad.net/cloud-init/+bug/1855170 was getting so much in the way, it broke my reading comprehension.

and that `-h -` was the correct implementation:

from http://man.freebsd.org/pw

      If a value of ‘-’ is given as the argument fd, then
      the password will be set to ‘*’, rendering the
      account inaccessible via password-based login.

Changed in cloud-init:
status: Fix Committed → Incomplete
Chad Smith (chad.smith) on 2019-12-17
Changed in cloud-init:
status: Incomplete → Invalid

This bug is believed to be fixed in cloud-init in version 19.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers