Re: [lmi] logname fails

[Greg Chicares]

On 2020-02-25 00:37, Vadim Zeitlin wrote:
[...]
>  Still, I just can't believe there is no way to get the user name from the
> user ID, does "ls -l" show you user IDs instead of names too? Also, I've
> realized that I didn't know if "id -nu" didn't work only inside chroot or
> inside the main system too?

I observed that failure only inside the chroot, and more specifically,
only when root enters the chroot as a normal user, as in:
  $sudo schroot --user=unprivileged_user_name ...
I've observed it only where 'schroot' is involved. I don't know what
would have happened in a case like
  $schroot --user=unprivileged_user_name ...
where an unprivileged host user enters the chroot as an unprivileged
chroot user.

Thanks for continuing to challenge this--it's led to a surprise.

I hadn't thought of checking what 'ls -l' prints, so, in order to
try it under exactly the same conditions as before, I consulted
this email:

On 2020-02-21 23:18, MY_CORPORATE_EMAIL_ACCOUNT wrote:
| /opt/lmi/src/lmi[0]$sudo zsh
|
| /opt/lmi/src/lmi[0]#schroot --chroot=chroot:lmi --user=REDACTED_NAME 
--directory=/tmp
| $ whoami
| whoami: cannot find name for user ID REDACTED_NUMBER

which I'm absolutely sure I copied directly from the PuTTY screen.
Cutting and pasting exactly those commands, today I observe a
different outcome--everything just works:

On 2020-02-25 14:56, Chicares, Greg wrote:
| /opt/lmi/src/lmi[0]$sudo zsh
| /opt/lmi/src/lmi[0]#schroot --chroot=chroot:lmi --user=REDACTED_NAME 
--directory=/tmp
| $ whoami
| REDACTED_NAME

I can't really say why, but I can speculate:

(1) Some sysadmin has done...something. I doubt that:
  sudo who --all
shows that the system was rebooted 20200219, but shows no login
by anyone but me since then. Nevertheless, I've installed etckeeper
so that I can examine any configuration changes in future.

(2) RHEL is somehow unstable, which would be surprising, though
maybe there's an external LDAP nameserver that was in some
undefined state for a few days after the last reboot.

(3) There's an unknown defect in 'schroot'. Or, more likely,
some experimental iteration of my setup scripts had set up a
chroot in some improper way that 'schroot' doesn't diagnose.
AIUI, 'schroot' makes some attempt to duplicate the host
system's users into the chroot's /etc/passwd , and maybe
something went haywire there. That would explain why calling
'ps' repeatedly from inside the chroot couldn't find my real
user name. Also AIUI, 'schroot' was created for use by debian
maintainers, who probably don't do much testing on redhat.
IOW, my guess is that the difference between the 20200221
failure and today's 20200225 success is that they used two
different (though identically named) chroots, and that last
week's had been created by a script iteration that had failed
to create the desired unprivileged user in the chroot.