[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#265795: Detailed explanation of the bug preventing user login



I think it is important to give a precise explanation of the bug
reported by many people about an impossibility of logging in using
the new kdm version, for the mantainer to reproduce it, and fix it properly.

Description:
------------

     After the upgrade to kdm 3.3.0-1, some users discover that they can
     no longer log in (kdm accepts the password, then nothing happens and
     the login screen appears again).

Explanation:
------------

     The new /etc/kde3/kdm/Xsession in kdm 3.3.0-1 tries to do some smart
     things, that include sourcing the appropriate environment variables
     depending on the user shell, and here is where the mechanics of the
     seeming irreproducibility of the bug lies.

     The code handling csh/tcsh is made up of the following lines

  */csh|*/tcsh)
    # [t]cshrc is always sourced automatically.
    # Note that sourcing csh.login after .cshrc is non-standard.
    set -a
    eval `$SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c set | egrep -v "^(BASH_VERSINFO|EUID|PPID|UID|_)="'`
    set +a
    ;;

     Now, IF /bin/sh on the machine happens to be actually a link to bash,
     everything works like a charm, BUT if /bin/sh is just the usual, plain
     old sh, then the execution of this line simply aborts the execution of
     the /etc/kde3/kdm/Xsession script (notice that the first line of the
     file is also #! /bin/sh, invoking /bin/sh that on many machines is
     an alias for /bin/bash, but not on all machines).

     As a consequence, on a machine where the user has csh/tcsh as shell, AND
     /bin/sh is NOT the same as /bin/bash, Xsession aborts, and the user
     sees the surprising behaviour of kdm "resetting"

Fix:
----

     On the machine I had at hand, I changed the occurrence of /bin/sh to
     /bin/bash in the first line of /etc/kde3/kdm/Xsession file, but of course,
     it would be better to understand WHY the execution of the script is
     stipped using the plain /bin/sh ...


Hope this helps in getting a rock solid new version of kdm

--Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur
PPS                      E-mail: roberto@dicosmo.org
Universite Paris VII     WWW  : http://www.dicosmo.org
Case 7014                
2, place Jussieu         
F-75251 Paris Cedex 05
FRANCE.                  
------------------------------------------------------------------
Attachments:
   MIME accepted
   Word deprecated, http://www.rfc1149.net/documents/whynotword
------------------------------------------------------------------



Reply to: