Re: single user machine, one "user" now(?) has no password (I didn't do it). [edited for clarity]

On Fri, Feb 20, 2026 at 03:36:00PM -0800, Samuel wrote:
> If I type it out on my phone are you willing to tell me what I'm not seeing?

Sure.

> I've done that below.
> It may worth repeating that I saw no issues with the other ten or so user
> accounts.

Subtle bugs show up all the time in code that looks reasonable at first
glance.

> I will show the password generator, if asked;

You'll probably need to show it if you want a definite conclusion.

> but I believe it will not
> output an empty string. (It mainly reads from /dev/random, to get printable
> characters, not very guessable, I would think.)

Does it cope with race conditions, (multiple invocations at the same time),
does it cope with I/O errors? We don't know.

> There would have to be something different about the invocation that
> generated this user, and I'm not seeing how that's possible.

It's possible.

> Here's the main script:

What are you even trying to do with this that cannot be done using more
standard tools rather than invoking vipw in a script?

> #!/bin/ksh
> userinfo -e "$1" && { print exists; exit 1;}
> [ -e /home/"$1" ] && { print ERR: \$HOME; exit 1;}
>
> uid=1000; until ! userinfo -e $uid; do ((++uid));done
> gid=1000; until ! userinfo -e $gid; do ((++gid));done
> pw="$(/somedir/pwgenenerator|encrypt -c localuser)"

There is _no_ error checking here for $pw being assigned a valid value.

If 'pwgenenerator', (I think you probably meant pwgenerator, by the way),
fails to run or outputs an empty string for some reason, you'll end up with an
empty string in $pw, and that will go _unchecked_.

(Also, good practice would be to specify the full path to /usr/bin/encrypt, it
might not matter so much here if this is a test setup on a single user
machine, but in general don't rely on $PATH to be what you think it will be
when writing scripts that run as root.)

If you show the password generator, we can see what might have gone wrong
there.