LOGNAME not properly set on FreeBSD

LOGNAME not properly set on FreeBSD

[Erik Johnson]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

When using "su - username" to change users, zsh is not properly setting
the LOGNAME environment variable on FreeBSD. Example below.

erik@virtubsd:~% zsh --version
zsh 5.0.2 (amd64-portbld-freebsd9.1)
erik@virtubsd:~% su - root
Password:
virtubsd# echo $LOGNAME
erik
virtubsd# cat .zshrc
cat: .zshrc: No such file or directory
virtubsd# logout
erik@virtubsd:~% sudo chpass -s /bin/csh root
Password:
chpass: user information updated
erik@virtubsd:~% su - root
Password:
virtubsd# echo $LOGNAME
root
virtubsd# logout


-- 

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: LOGNAME not properly set on FreeBSD

[Erik Johnson]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Tue, Apr 01, 2014 at 04:22:39PM -0500, Erik Johnson wrote:
>When using "su - username" to change users, zsh is not properly setting
>the LOGNAME environment variable on FreeBSD. Example below.
>
>erik@virtubsd:~% zsh --version
>zsh 5.0.2 (amd64-portbld-freebsd9.1)
>erik@virtubsd:~% su - root
>Password:
>virtubsd# echo $LOGNAME
>erik
>virtubsd# cat .zshrc
>cat: .zshrc: No such file or directory
>virtubsd# logout
>erik@virtubsd:~% sudo chpass -s /bin/csh root
>Password:
>chpass: user information updated
>erik@virtubsd:~% su - root
>Password:
>virtubsd# echo $LOGNAME
>root
>virtubsd# logout
>
>

I just built and installed 5.0.5, and the issue persists there as well.


-- 

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: LOGNAME not properly set on FreeBSD

[Phil Pennock]

On 2014-04-01 at 16:22 -0500, Erik Johnson wrote:
> When using "su - username" to change users, zsh is not properly setting
> the LOGNAME environment variable on FreeBSD. Example below.

----------------------------8< cut here >8------------------------------
 LOGNAME
    If the corresponding variable is not set in the  environment  of
    the  shell, it is initialized to the login name corresponding to
    the current login session. This parameter is exported by default
    but this can be disabled using the typeset builtin.
----------------------------8< cut here >8------------------------------

This is the _login_ name, as a convenience, it's not the _current_ name,
and is not defined as such.  The whole point is that if you su to
another account, LOGNAME can persist as the original.  It's not
_trustworthy_, but might be used to let you have a .zshrc.staff.$LOGNAME
file which might be auto-sourced, or whatever else you want.

If you do:

    % typeset +x LOGNAME

then LOGNAME won't be exported.

> erik@virtubsd:~% su - root
> Password:
> virtubsd# echo $LOGNAME
> erik

Yup, that's exactly what it's supposed to do.

You might want USERNAME instead of LOGNAME ?

-Phil

Re: LOGNAME not properly set on FreeBSD

[Erik Johnson]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Tue, Apr 01, 2014 at 08:27:46PM -0400, Phil Pennock wrote:
>On 2014-04-01 at 16:22 -0500, Erik Johnson wrote:
>> When using "su - username" to change users, zsh is not properly setting
>> the LOGNAME environment variable on FreeBSD. Example below.
>
>----------------------------8< cut here >8------------------------------
> LOGNAME
>    If the corresponding variable is not set in the  environment  of
>    the  shell, it is initialized to the login name corresponding to
>    the current login session. This parameter is exported by default
>    but this can be disabled using the typeset builtin.
>----------------------------8< cut here >8------------------------------
>
>This is the _login_ name, as a convenience, it's not the _current_ name,
>and is not defined as such.  The whole point is that if you su to
>another account, LOGNAME can persist as the original.  It's not
>_trustworthy_, but might be used to let you have a .zshrc.staff.$LOGNAME
>file which might be auto-sourced, or whatever else you want.
>
>If you do:
>
>    % typeset +x LOGNAME
>
>then LOGNAME won't be exported.
>

The whole point of "su -" (and "su -l", which are equivalent), is to
make the session a login session.

http://www.unix.com/man-page/FreeBSD/1/SU/

So, LOGNAME should be set appropriately in those cases. I can understand
not setting LOGNAME when su is invoked without "-" or "-l", because that
doesn't create a login session. But not setting it for login shells is
incorrect behavior.

>> erik@virtubsd:~% su - root
>> Password:
>> virtubsd# echo $LOGNAME
>> erik
>
>Yup, that's exactly what it's supposed to do.
>

No, it's not, as I noted above.

>You might want USERNAME instead of LOGNAME ?
>
>-Phil


Nope. The current behavior breaks python's getpass.getuser()
(https://docs.python.org/2/library/getpass.html#getpass.getuser), which
relies on a properly-set LOGNAME.


-- 

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: LOGNAME not properly set on FreeBSD

[Phil Pennock]

On 2014-04-01 at 19:50 -0500, Erik Johnson wrote:
> The whole point of "su -" (and "su -l", which are equivalent), is to
> make the session a login session.

Then it's su's responsibility to clear/reset/set environment variables
associated with the login.

In fact, SUSv4 is pretty clear on this:
----------------------------8< cut here >8------------------------------
LOGNAME
  The system shall initialize this variable at the time of login to be
  the user's login name. See <pwd.h> . For a value of LOGNAME to be
  portable across implementations of POSIX.1-2008, the value should be
  composed of characters from the portable filename character set.
----------------------------8< cut here >8------------------------------

Note "at the time of login".  The fact that zsh will fix up a _missing_
LOGNAME variable is a shell convenience, for a broken system which
didn't do what it should have done at login time.

So either su is leaving LOGNAME set across the security boundary, or
libc's getlogin() continues to report the old value after the su.

In another sub-thread, you perform a bunch of tests with python2's
getpass.getuser() function, but please note that this function
preferentially uses environment variables and doesn't report which
variable it sourced from, so is problematic for tracing the source of a
problem.  That function will try, in turn: LOGNAME USER LNAME USERNAME;
after that, it uses a passwd lookup of the current uid, _not_
getlogin().  Thus the evidence purporting to show that it "just works"
in other shells isn't actually showing that.

Running >> env - bash --login << I see that I have a login shell and
that LOGNAME is not set, thus bash is not performing any such fixup and
if you see correct values in your tests, what you're seeing is likely
Python's getpass.getuser() reaching the pwd.getpwuid(os.getuid())[0]
step.

So yes, in such a scenario you'll get a different result from zsh which
fixes up the missing LOGNAME from the libc getlogin(), thus returns
whatever the OS's concept of "the user's login name" is.

-Phil

Re: LOGNAME not properly set on FreeBSD

[Erik Johnson]

[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]

On Wed, Apr 02, 2014 at 04:54:13PM -0400, Phil Pennock wrote:
>On 2014-04-01 at 19:50 -0500, Erik Johnson wrote:
>> The whole point of "su -" (and "su -l", which are equivalent), is to
>> make the session a login session.
>
>Then it's su's responsibility to clear/reset/set environment variables
>associated with the login.
>
>In fact, SUSv4 is pretty clear on this:
>----------------------------8< cut here >8------------------------------
>LOGNAME
>  The system shall initialize this variable at the time of login to be
>  the user's login name. See <pwd.h> . For a value of LOGNAME to be
>  portable across implementations of POSIX.1-2008, the value should be
>  composed of characters from the portable filename character set.
>----------------------------8< cut here >8------------------------------
>
>Note "at the time of login".  The fact that zsh will fix up a _missing_
>LOGNAME variable is a shell convenience, for a broken system which
>didn't do what it should have done at login time.
>
>So either su is leaving LOGNAME set across the security boundary, or
>libc's getlogin() continues to report the old value after the su.
>
>In another sub-thread, you perform a bunch of tests with python2's
>getpass.getuser() function, but please note that this function
>preferentially uses environment variables and doesn't report which
>variable it sourced from, so is problematic for tracing the source of a
>problem.  That function will try, in turn: LOGNAME USER LNAME USERNAME;
>after that, it uses a passwd lookup of the current uid, _not_
>getlogin().  Thus the evidence purporting to show that it "just works"
>in other shells isn't actually showing that.
>
>Running >> env - bash --login << I see that I have a login shell and
>that LOGNAME is not set, thus bash is not performing any such fixup and
>if you see correct values in your tests, what you're seeing is likely
>Python's getpass.getuser() reaching the pwd.getpwuid(os.getuid())[0]
>step.
>

Good point:

erik@virtubsd:~% sudo chpass -s /bin/csh root
Password:
chpass: user information updated
erik@virtubsd:~%  su -
Password:
virtubsd# echo $LOGNAME
root
virtubsd# logout
erik@virtubsd:~% sudo chpass -s /bin/tcsh root
chpass: user information updated
erik@virtubsd:~% su -
Password:
virtubsd# echo $LOGNAME
root
virtubsd# logout
erik@virtubsd:~% sudo chpass -s /usr/local/bin/bash root
chpass: user information updated
erik@virtubsd:~% su -
Password:
[root@virtubsd ~]# echo $LOGNAME

[root@virtubsd ~]# logout
erik@virtubsd:~% sudo chpass -s /usr/local/bin/ksh93 root
chpass: user information updated
erik@virtubsd:~% su -
Password:
# echo $LOGNAME

# ^D
erik@virtubsd:~% sudo chpass -s /usr/local/bin/zsh root
chpass: user information updated
erik@virtubsd:~% su -
Password:
virtubsd# echo $LOGNAME
erik
virtubsd#

>So yes, in such a scenario you'll get a different result from zsh which
>fixes up the missing LOGNAME from the libc getlogin(), thus returns
>whatever the OS's concept of "the user's login name" is.
>
>-Phil

-- 

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: LOGNAME not properly set on FreeBSD

[Peter Stephenson]

On Tue, 01 Apr 2014 16:22:39 -0500
Erik Johnson <palehose@gmail.com> wrote:
> When using "su - username" to change users, zsh is not properly setting
> the LOGNAME environment variable on FreeBSD. Example below.
> 
> erik@virtubsd:~% zsh --version
> zsh 5.0.2 (amd64-portbld-freebsd9.1)
> erik@virtubsd:~% su - root
> Password:
> virtubsd# echo $LOGNAME
> erik

From the code, it looks like this would only happen if getlogin() is
returning the wrong thing, i.e. "erik", or it's not returning anything
and the shell is having to guess and doing so wrongly.  Although that
doesn't seem very likely it's hard to see another way this can happen
within the shell.  Presumably

python -c 'import os; print os.getlogin()'

prints "root"?

It might also be useful to start the shell with the "-x" option to check
all the initialisation scripts.  I'm not sure you can do that with su
without some fiddling but you could put "set -x" temporarily at the top
of /etc/zshenv.

pws

Re: LOGNAME not properly set on FreeBSD

[Erik Johnson]

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]

On Wed, Apr 02, 2014 at 10:23:48AM +0100, Peter Stephenson wrote:
>On Tue, 01 Apr 2014 16:22:39 -0500
>Erik Johnson <palehose@gmail.com> wrote:
>> When using "su - username" to change users, zsh is not properly setting
>> the LOGNAME environment variable on FreeBSD. Example below.
>>
>> erik@virtubsd:~% zsh --version
>> zsh 5.0.2 (amd64-portbld-freebsd9.1)
>> erik@virtubsd:~% su - root
>> Password:
>> virtubsd# echo $LOGNAME
>> erik
>
>From the code, it looks like this would only happen if getlogin() is
>returning the wrong thing, i.e. "erik", or it's not returning anything
>and the shell is having to guess and doing so wrongly.  Although that
>doesn't seem very likely it's hard to see another way this can happen
>within the shell.  Presumably
>
>python -c 'import os; print os.getlogin()'
>
>prints "root"?
>
>It might also be useful to start the shell with the "-x" option to check
>all the initialisation scripts.  I'm not sure you can do that with su
>without some fiddling but you could put "set -x" temporarily at the top
>of /etc/zshenv.
>
>pws

Python os.getlogin() does indeed show "erik" instead of "root". So this
may just be a difference between glibc and BSD libc. Either way, it
"just works" in bash, sh, csh, tcsh, and ksh, as can be seen below, so
I believe there is an argument for making it work properly in FreeBSD as
well, or at the very least adding some wording to the zshparam manpage
which makes this difference in behavior clear.


erik@virtubsd:~% sudo chpass -s /bin/sh root
Password:
chpass: user information updated
# erik@virtubsd:~% su -
Password:
# python2 -c 'import getpass; print getpass.getuser()'
root
# ^D%
# erik@virtubsd:~% sudo chpass -s /usr/local/bin/bash root
chpass: user information updated
[root@virtubsd ~]# python2 -c 'import getpass; print getpass.getuser()'
root
[root@virtubsd ~]# logout
erik@virtubsd:~% sudo chpass -s /bin/tcsh root
chpass: user information updated
erik@virtubsd:~% su -
Password:
virtubsd# python2 -c 'import getpass; print getpass.getuser()'
root
virtubsd# logout
erik@virtubsd:~% sudo chpass -s /usr/local/bin/ksh93 root
Password:
chpass: user information updated
erik@virtubsd:~% su -
Password:
# python2 -c 'import getpass; print getpass.getuser()'
root
# ^D
erik@virtubsd:~% sudo chpass -s /usr/local/bin/zsh root
chpass: user information updated
erik@virtubsd:~% su -
Password:
virtubsd# python2 -c 'import getpass; print getpass.getuser()'
erik


-- 

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: LOGNAME not properly set on FreeBSD

[Peter Stephenson]

On Wed, 2 Apr 2014 14:06:21 -0500
Erik Johnson <palehose@gmail.com> wrote:
> Python os.getlogin() does indeed show "erik" instead of "root". So this
> may just be a difference between glibc and BSD libc. Either way, it
> "just works" in bash, sh, csh, tcsh, and ksh, as can be seen below, so
> I believe there is an argument for making it work properly in FreeBSD as
> well, or at the very least adding some wording to the zshparam manpage
> which makes this difference in behavior clear.

Hmm...  to me, having LOGNAME *not* report the same as getlogin() is
"just not working".  Presumably there's some reason why getlogin() does
what it does and it doesn't seem to me to be the shell's job to second
guess system calls.  POSIX seems to agree with me --- to be fair, this
isn't for the variable, it's for the command "logname", but it would be
confusing if they were different.

  The logname utility shall write the user's login name to standard
  output. The login name shall be the string that would be returned by
  the getlogin() function defined in the System Interfaces volume of
  POSIX.1-2008. Under the conditions where the getlogin() function would
  fail, the logname utility shall write a diagnostic message to standard
  error and exit with a non-zero exit status.

However, there may be some documented prior art for LOGNAME that I'm
missing --- the history of shell development isn't necessarily particularly
rational.

It certainly makes sense to document it in any case.

diff --git a/Doc/Zsh/params.yo b/Doc/Zsh/params.yo
index cf2ad34..8d95355 100644
--- a/Doc/Zsh/params.yo
+++ b/Doc/Zsh/params.yo
@@ -621,7 +621,9 @@ item(tt(LOGNAME))(
 If the corresponding variable is not set in the environment of the
 shell, it is initialized to the login name corresponding to the
 current login session. This parameter is exported by default but
-this can be disabled using the tt(typeset) builtin.
+this can be disabled using the tt(typeset) builtin.  The value
+is set to the string returned by the manref(getlogin)(3) system call
+if that is available.
 )
 vindex(MACHTYPE)
 item(tt(MACHTYPE))(


-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: LOGNAME not properly set on FreeBSD

[Erik Johnson]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

On Wed, Apr 02, 2014 at 09:58:54PM +0100, Peter Stephenson wrote:
>On Wed, 2 Apr 2014 14:06:21 -0500
>Erik Johnson <palehose@gmail.com> wrote:
>> Python os.getlogin() does indeed show "erik" instead of "root". So this
>> may just be a difference between glibc and BSD libc. Either way, it
>> "just works" in bash, sh, csh, tcsh, and ksh, as can be seen below, so
>> I believe there is an argument for making it work properly in FreeBSD as
>> well, or at the very least adding some wording to the zshparam manpage
>> which makes this difference in behavior clear.
>
>Hmm...  to me, having LOGNAME *not* report the same as getlogin() is
>"just not working".  Presumably there's some reason why getlogin() does
>what it does and it doesn't seem to me to be the shell's job to second
>guess system calls.  POSIX seems to agree with me --- to be fair, this
>isn't for the variable, it's for the command "logname", but it would be
>confusing if they were different.
>
>  The logname utility shall write the user's login name to standard
>  output. The login name shall be the string that would be returned by
>  the getlogin() function defined in the System Interfaces volume of
>  POSIX.1-2008. Under the conditions where the getlogin() function would
>  fail, the logname utility shall write a diagnostic message to standard
>  error and exit with a non-zero exit status.
>
>However, there may be some documented prior art for LOGNAME that I'm
>missing --- the history of shell development isn't necessarily particularly
>rational.
>
>It certainly makes sense to document it in any case.
>

Yeah, and for what it's worth it seems that not all of the shells are
exporting LOGNAME. But the ones that do are apparently doing so
differently than zsh does it. So, documentation is probably the best
route to go here. Thanks!


-- 

-Erik

"For me, it is far better to grasp the universe as it really is than to
persist in delusion, however satisfying and reassuring."  --Carl Sagan


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]