Hi Colin,

With your response, i've checked more into the Nix shell efect on the different 
registers impacted on generation.
The generation of the Nix shell do not update de utmp file as he inherit from 
profile configuration.

I haven't checked the date of this known behaviour but here there is a perfect 
resume : https://www.man7.org/linux/man-pages/man3/getlogin.3.html 
```
# BUGS
       Unfortunately, it is often rather easy to fool getlogin().
       Sometimes it does not work at all, because some program messed up
       the utmp file.  Often, it gives only the first 8 characters of the
       login name.  The user currently logged in on the controlling
       terminal of our program need not be the user who started it.
       Avoid getlogin() for security-related purposes.

       Note that glibc does not follow the POSIX specification and uses
       stdin instead of /dev/tty.  A bug.  (Other recent systems, like
       SunOS 5.8 and HP-UX 11.11 and FreeBSD 4.8 all return the login
       name also when stdin is redirected.)
```
We can notice this effects in the test-gelogin.h file.
# test-getlogin.h ; 33 - 48
static void
test_getlogin_result (const char *buf, int err)
{
  if (err != 0)
    {
      if (err == ENOENT)
        {
          /* This can happen on GNU/Linux.  */
          fprintf (stderr, "Skipping test: no entry in utmp file.\n");
          exit (77);
        }

      ASSERT (err == ENOTTY
              || err == EINVAL /* seen on Linux/SPARC */
              || err == ENXIO
             );


So, as this behaviour is known, I proposed to put this bug under the carpet :)

Have a nice day,
Florian
________________________________________
De : Collin Funk <[email protected]>
Envoyé : vendredi 6 février 2026 05:36
À : DUZES Florian
Cc : [email protected]
Objet : Re: bug#80338: BUG report - getlogin

Hi,

DUZES Florian <[email protected]> writes:

> Hello,
>
> I was playing around with 'make check' in my NIX shell define as :
>
>  {inputs.nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
>
> outputs = { self, nixpkgs}:
>     let
>       system = "x86_64-linux";
>       pkgs = import nixpkgs { inherit system; };
>     in {
>       devShells.x86_64-linux.default = pkgs.mkShell {
>         buildInputs = with pkgs; [
>
>         ];
>         shellHook = ''
>           export PS1="\[\033[1;32m\](flake:\W)\[\033[0m\] $ "
>         '';
>       };
>     };
> }
>
> And I encounter this behaviour.
>
> ============================================================================
> FAIL: test-getlogin
> ===================
>
> test-getlogin.h:113: assertion 'pwd->pw_uid == stat_buf.st_uid' failed
> FAIL test-getlogin (exit status: 134)
>
> ============================================================================
> Testsuite summary for GNU coreutils 9.9
> ============================================================================
> # TOTAL: 574
> # PASS:  480
> # SKIP:  93
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> ============================================================================
> As presented in the console log, this is my system information :
>
> Linux flodarpie 6.14.0-37-generic #37~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu 
> Nov 20 10:25:38 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
>
> I'm available for more details.

Thanks for the report.

This is file is imported from Gnulib, so I have removed coreutils from
the CC and added [email protected].

I see that Nix has had this test disabled for a long time on musl [1].
But it is interesting that you see it on glibc.

Here is the test that is failing:

    struct stat stat_buf;
    ASSERT (fstat (STDIN_FILENO, &stat_buf) == 0);

    /* Here BUF is the result of getlogin.  */
    struct passwd *pwd = getpwnam (buf);
    if (! pwd)
      {
        fprintf (stderr, "Skipping test: %s: no such user\n", buf);
        exit (77);
      }

    ASSERT (pwd->pw_uid == stat_buf.st_uid);

Maybe someone more familiar with Nix knows what is happening here?

Collin

[1] 
https://github.com/NixOS/nixpkgs/commit/2f7bf95f51ab7e612efc67dde9131bb3e33c4959

Reply via email to