In Oneiric beta2, env variable $LOGNAME is blank/null

Bug #864109 reported by Chris
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Light Display Manager
Fix Released
Undecided
Unassigned

Bug Description

This is a new install done this morning, and fully updated twice today. The problem came to my attention when a backup script failed, which was traced to the fact that $LOGNAME variable was null.

I understand that the $LOGNAME variable "should not be relied on as it can be changed" however I'm sure a great number of backup scripts have used it over years since it was introduced in UNIX III. No previous Ubuntu releases have had a problem as far as I'm aware.

I originally asked a question on Launchpad as I wasn't sure if this was a bug:
https://answers.launchpad.net/ubuntu/+source/bash/+question/172882
however the respondent~andrew-woodhead666 demonstrated that his $LOGNAME variable was _not_ blank, even though the two systems should be equivalent.

As a final test update manager was run and the system was rebooted, and it was verified that $LOGNAME was still null.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: bash 4.2-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-12.19-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu2
Architecture: i386
Date: Sun Oct 2 00:16:19 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta i386 (20110921.2)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 LANGUAGE=en_AU:en
SourcePackage: bash
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Chris (fabricator4) wrote :
Revision history for this message
Chris (fabricator4) wrote :

I believe this is related to core-utils, as per the man page on #LOGNAME

affects: bash (Ubuntu) → coreutils
Revision history for this message
Louis-Dominique Dubeau (ldd) wrote :

I've also encountered this bug on Ubuntu 11.10.

However, I found the following:

1. If I log in from a text console or if I invoke login manually, LOGNAME is set properly.

2. If I log in using X, then LOGNAME is not set.

Preliminary investigation leads me to believe that the problem is with lightdm. The file src/session.c contains the following code:

gboolean
session_start (Session *session)
{
    User *user;

    g_return_val_if_fail (session != NULL, FALSE);
    g_return_val_if_fail (session->priv->authentication != NULL, FALSE);
    g_return_val_if_fail (session->priv->command != NULL, FALSE);

    g_debug ("Launching session");

    user = pam_session_get_user (session->priv->authentication);
    session_set_env (session, "PATH", "/usr/local/bin:/usr/bin:/bin");
    session_set_env (session, "USER", user_get_name (user));
    session_set_env (session, "USERNAME", user_get_name (user)); // FIXME: Is this required?
    session_set_env (session, "HOME", user_get_home_directory (user));
    session_set_env (session, "SHELL", user_get_shell (user));

    return SESSION_GET_CLASS (session)->start (session);
}

LOGNAME is absent. There does not seem to be any other opportunity to set LOGNAME in for a new session.

This is what is installed on my machine:

$ apt-cache policy lightdm
lightdm:
  Installed: 1.0.1-0ubuntu6
  Candidate: 1.0.1-0ubuntu6
  Version table:
 *** 1.0.1-0ubuntu6 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Chris (fabricator4) wrote :

Fixed in LightDM since Oneiric release

no longer affects: coreutils
Changed in lightdm:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.