Skip to content

Conversation

@ogayot
Copy link
Member

@ogayot ogayot commented Nov 25, 2025

In general, if we pass an encrypted password using the --password option of useradd, then we need to make sure that the invocation is not logged anywhere.

This is challenging to do. Furthermore, in Subiquity, we run useradd through systemd-run, so the command automatically gets recorded in the journal as a transient unit.

To avoid the problem, we now call useradd without the password option, and then immediately call chpasswd to update the password, using stdin.

Marking as a draft until I test in a VM.

Depends on https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/496404

Copy link
Contributor

@Chris-Peterson444 Chris-Peterson444 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, LGTM. Tentative yes based on the VM tests showing no logged passwords on the chpasswd call.

Thanks!

We can now pass input when calling runner.run() using the "input" argument.
That said, because of how reading stdin is implemented in systemd-run, using
input="something" will cause stdout and stderr to not end up in the journal.

Therefore, we currently only allow input="something" in combination with
capture=True.

In the future, it would be good to support one without the other.

Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
@ogayot ogayot force-pushed the chpasswd branch 2 times, most recently from 15859b0 to 62e9a9b Compare November 26, 2025 14:56
@ogayot
Copy link
Member Author

ogayot commented Nov 26, 2025

Well, the original implementation was far from a working implementation. The following problems were found during testing and have been resolved:

  • The input parameter was incorrectly forwarded to astart_command, which didn't support it. We now work with the stdin parameter in runner.start and forward the input to proc.communicate via runner.wait.
  • curtin's in-target was ignoring stdin, so the call to chpasswd ended up being a noop. See https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/496404
  • run_curtin_command wasn't forwarding the arguments properly to the runner

@ogayot ogayot marked this pull request as ready for review November 27, 2025 11:16
Comment on lines -81 to -83
source: https://git.launchpad.net/curtin
source: https://git.launchpad.net/~ogayot/curtin
source-type: git
source-commit: "ff79541249aa40f228f87681cdb028c69975cd8c"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To update once the MP has been merged.

Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In general, if we pass an encrypted password using the --password option of
useradd, then we need to make sure that the invocation is not logged anywhere.

This is challenging to do, especially in Subiquity where we run useradd through
systemd-run. Indeed the command automatically gets recorded in the journal as a
transient unit.

To avoid the problem, we now call useradd without the password option, and then
immediately call chpasswd to update the password, using stdin.

Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
",".join(sorted(groups)),
"--create-home",
]
async def run_in_target(cmd: list[str], **kwargs):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(future PR) we have 13 places where we run "in-target", moving a helper like this to subiquity/server/curtin.py would help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants