From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20349 invoked by alias); 2 Apr 2014 20:54:31 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32520 Received: (qmail 25020 invoked from network); 2 Apr 2014 20:54:17 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201312; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=HuMXYjpKB3F7lAL2DoFCqbVb9YqvLvI271DA8LAfapo=; b=WpCtJqphD/EarB7Te4YlDlLoDjOpsPZ6cxzRSvBpZSNr5m+vFkPM9Q9M8YYxNqKSkGMGXa86PyMlmccEbScZTot80kS+KdPRkLMZMpACeg8E6LtdUDbiWVwGCm3fHKJ/+aQqfBnp7zFpp1mx3nz4d1tn+k0nSvji6hQIuxCErKmiQEbI/FBWEgaCRmUvLOi53rWOqYvPWTYWOBrb; Date: Wed, 2 Apr 2014 16:54:13 -0400 From: Phil Pennock To: Erik Johnson Cc: zsh-workers@zsh.org Subject: Re: LOGNAME not properly set on FreeBSD Message-ID: <20140402205413.GA38843@redoubt.spodhuis.org> Mail-Followup-To: Erik Johnson , zsh-workers@zsh.org References: <20140401212239.GE20508@gmail.com> <20140402002746.GA25309@redoubt.spodhuis.org> <20140402005002.GG20508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140402005002.GG20508@gmail.com> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x3903637F.asc 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 . 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