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