GNU bug report logs - #18386
logname fails with error "logname: no login name" (is there an echo in here)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18386 in the body.
You can then email your comments to 18386 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: logname fails with error "logname: no login name" (is there an echo
 in here)
Date: Mon, 01 Sep 2014 17:06:03 -0700

This is at a pty:
>  tty
/dev/pts/0
>  logname
logname: no login name
>  logname --version
logname (GNU coreutils) 8.21
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by FIXME: unknown.
----

I notice that while 'whoami' prints my login name (as does "id" with a 
bunch of groups),


The "who" command also seems AWOL
Ishtar:/> who --version
who (GNU coreutils) 8.21
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Joseph Arceneaux, David MacKenzie, and Michael Stone.
Ishtar:/> who -a
Ishtar:/> who -t
Ishtar:/> who -u
Ishtar:/> who -b
Linux Ishtar 3.16.0-Isht-Van #1 SMP PREEMPT Tue Aug 12 11:11:02 PDT 2014 
x86_64 x86_64 x86_64 GNU/Linux

I wonder if the who command's output being broken is related?

Distro is a 13.1 SuSE base, but wouldn't call it a stock system (still 
boots w/sysvinit)

Message #8 received at 18386 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Linda Walsh <coreutils <at> tlinx.org>, 18386 <at> debbugs.gnu.org
Subject: Re: bug#18386: logname fails with error "logname: no login name"
 (is there an echo in here)
Date: Tue, 02 Sep 2014 12:35:58 +0200

On 09/02/2014 02:06 AM, Linda Walsh wrote:
>>  logname
> logname: no login name

logname(1) works here on a regular openSUSE-13.1 system, and
just calls getlogin(3) to get the information as required:

  $ ltrace logname
  ...
  getlogin()                 = "berny"

which in turn seems to retrieve the information like this:

  $ strace logname
  ...
  open("/proc/self/loginuid", O_RDONLY)   = 3
  read(3, "717", 12)                      = 3
  close(3)                                = 0
  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
  connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = 0
  sendto(3, "\2\0\0\0\v\0\0\0\7\0\0\0passwd\0", 19, MSG_NOSIGNAL, NULL, 0) = 19
  ...

Don't you have /proc mounted?

> Ishtar:/> who -a
> Ishtar:/> who -t
> Ishtar:/> who -u
> Ishtar:/> who -b
> Linux Ishtar 3.16.0-Isht-Van #1 SMP PREEMPT Tue Aug 12 11:11:02 PDT 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> I wonder if the who command's output being broken is related?

Similar for who(1) here:

  $ strace who
  ...
  open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = 3
  ...

> Distro is a 13.1 SuSE base, but wouldn't call it a stock system (still boots w/sysvinit)

It looks like trying to avoid systemd is not that easy ...

Have a nice day,
Berny

Message #11 received at 18386 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 18386 <at> debbugs.gnu.org
Subject: Re: bug#18386: logname fails with error "logname: no login name"
 (is	there an echo in here)
Date: Wed, 03 Sep 2014 02:06:55 -0700

Bernhard Voelker wrote:
> On 09/02/2014 02:06 AM, Linda Walsh wrote:
>>>  logname
>> logname: no login name
> 
> logname(1) works here on a regular openSUSE-13.1 system, and
> just calls getlogin(3) to get the information as required:
> 
>   $ ltrace logname
>   ...
>   getlogin()                 = "berny"
----
With the same I get:
 ltrace -f logname|& more
[pid 40807] __libc_start_main(0x4017c0, 1, 0x7fff8b0306f8, 0x4042d0 <unfinished ...>
[pid 40807] strrchr("logname", '/')              = nil
[pid 40807] setlocale(LC_ALL, "")                = 
"LC_CTYPE=en_US.UTF-8;LC_NUMERIC="...
[pid 40807] bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
[pid 40807] textdomain("coreutils")              = "coreutils"
[pid 40807] __cxa_atexit(0x401c20, 0, 0, 0x736c6974756572) = 0
[pid 40807] getopt_long(1, 0x7fff8b0306f8, "", 0, nil) = -1
[pid 40807] getlogin()                           = nil
----

> 
> which in turn seems to retrieve the information like this:
> 
>   $ strace logname
>   ...
>   open("/proc/self/loginuid", O_RDONLY)   = 3
----
	I don't have a /proc/self/loginuid


How is it enabled in a vanilla kernel?


>   read(3, "717", 12)                      = 3
>   close(3)                                = 0
>   socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
>   connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) 
> = 0
>   sendto(3, "\2\0\0\0\v\0\0\0\7\0\0\0passwd\0", 19, MSG_NOSIGNAL, NULL, 
> 0) = 19
>   ...
> 
> Don't you have /proc mounted?
---
Yup.... mine is stock from kernel.org

I don't recall seeing any option for loginuid.

What module is it?  I probably don't have it mounted.

Message #14 received at 18386 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 18386 <at> debbugs.gnu.org
Subject: Re: bug#18386: logname fails with error "logname: no login name"
 (is	there an echo in here)
Date: Wed, 03 Sep 2014 02:18:57 -0700

I do not have auditing nor selinux incorporated, nor do
I really want to.

Seems like glibc relying on having a specific security model
loaded would seem to be a bug.

I.e. It should work on normal linux security without extra
security modules configed.

BTW I specifically try to specify differences between my
installation and standard in case they do contribute to any
problems.  It wouldn't be in my interest to complicate issues
by hiding such details.  Whether or not they 'should' be relevant
is another matter though....

That's why i try to operate with vanilla objects of some things (kernels
being most common) in my installation as a bellwether
for compatibility.

Message #17 received at 18386 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 18386 <at> debbugs.gnu.org
Subject: Re: bug#18386: logname fails with error "logname: no login name"
 (is	there an echo in here)
Date: Wed, 03 Sep 2014 12:12:18 +0200

tag 18386 notabug
close 18386
stop

On 09/03/2014 11:06 AM, Linda Walsh wrote:
> Bernhard Voelker wrote:
>>   open("/proc/self/loginuid", O_RDONLY)   = 3
> ----
>      I don't have a /proc/self/loginuid
>
>
> How is it enabled in a vanilla kernel?
...
> Yup.... mine is stock from kernel.org
>
> I don't recall seeing any option for loginuid.
>
> What module is it?  I probably don't have it mounted.

Thanks for getting back.
I don't know why getlogin() is using /proc/self/loginuid on openSUSE,
and why their kernels provide that file while a vanilla kernel does not.
I think this issue should be discussed downstreams.
Anyway, as this is clearly not an issue with logname(1) and how it
uses getlogin(), I'm marking this as not a bug.

Have a nice day,
Berny

Message #20 received at 18386 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 18386 <at> debbugs.gnu.org
Subject: Re: bug#18386: logname fails with error "logname: no login
 name"	(is	there an echo in here)
Date: Fri, 19 Sep 2014 17:45:31 -0700

Linda Walsh wrote:
>
> I do not have auditing nor selinux incorporated, nor do
> I really want to.
>
> Seems like glibc relying on having a specific security model
> loaded would seem to be a bug.
>
> I.e. It should work on normal linux security without extra
> security modules configed.
----
   BTW, FWIW, including audit in the kernel enables this
command to work, though "who" is still snafu'd...
That's a more complicated issue as not only has
the login table moved, but it's maintenance has been moved
to systemd...

Would have been nice if they'd updated the standalone version to
work and had systemd use that, but .. it's part of the
systemd-lockin-mentality.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.