Re: [lmi] logname fails

[Greg Chicares]

On 2020-02-24 19:38, Vadim Zeitlin wrote:
> On Mon, 24 Feb 2020 18:35:23 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> If I
> GC>   sudo [... whatever]
> GC>   schroot [...whatever]
> GC> then 'logname' returns my unprivileged login name on my debian machine,
> GC> but not on a corporate redhat server. See this branch:
> GC>   http://git.savannah.nongnu.org/cgit/lmi.git/log/?h=odd/rh_server
> GC> 
> GC> The only purpose of this email is preemptively to answer the question:
> GC> "can't you get that information with pstree though?".
> 
>  I hadn't thought about this question, but I did think about 2 other ones.
> First one was related to the comment in the commit above: could we solve
> the problem by defining some LMI_USERNAME environment variable which could
> be inherited by sudo if its "-E" option were used, and would, hopefully, be
> propagated inside chroot too? This wouldn't be dependent on user home
> location.

That's less ugly than walking through ps's PID->PPID chain.
But it replaces restrained ugliness with brutal elegance:
using '-E' feels like poor security. OTOH, anyone who has
my 2FA credentials can sign in as me and run 'sudo' with
any arguments at all, so I guess I shouldn't be concerned
about this.

And actually I can use the equivalent 'schroot' flag:

  $ sudo -E schroot --chroot=lmi --user=root --directory=/tmp \
      --preserve-environment env |grep "$(logname)\|$(id -u "$(logname)")"

That command gives me
  SUDO_UID
  SUDO_USER
  SUDO_GID
but no group name.

Still, the "type=plain" schroot that I've been using is no
longer supported, so I need to figure out how to use at
least "type=directory" anyway, and then:
 - I should be able to pass data like this with '--option', and
 - directories like /proc can be mounted by schroot
so that's the route I'm pursuing.

>  Second is more directly related to your question above: it looks like it
> would be much simpler to get this information from /proc/self/loginuid than
> from pstree output.

When the only applicable tool one knows how to use is 'ps',
then 'ps' becomes a Golden Hammer. Thanks for expanding my
repertoire. Still, there's no /proc/self/login_name . And
what I really want to do is enter a newly-created chroot
as root and run 'useradd' with my login name and UID, and
then 'groupadd' likewise with my default group and GUID
(or group "lmi" and its GUID on the redhat system).

>  OTOH a quick web search also found this question which might be relevant:
> 
> https://stackoverflow.com/questions/18570177/getpwuid-returns-null-for-ldap-user
> 
> It dates from 2013 and your problem is definitely not due to lack of 32 bit
> libraries, but I wonder if /lib64/libnss_sss.so might be missing on your
> system?

It is present:

$ls -l /lib64/libnss_sss.so.2
-rwxr-xr-x. 1 root root 37168 Oct  9 08:23 /lib64/libnss_sss.so.2