Re: Login Shell/Profile: Stop the Madness

From: Michael B Allen (mba2000_at_ioplex.com)
Date: 06/17/04

  • Next message: Zenaan Harkness: "Re: getting X standard background with metacity" 
    Date: Thu, 17 Jun 2004 01:14:41 -0400
To: Michael Graham <oobermick@yahoo.co.uk>

    On Thu, 17 Jun 2004 03:44:50 +0100
    Michael Graham <oobermick@yahoo.co.uk> wrote:

    > Michael wrote:
    > > After much consternation I feel the need to vent about shell
    > > environment initialization. With the default Debian installation,
    > > /etc/profile and~/.bash_profile are not sourced in the X windows
    > > environment. Apparently this is because at no time is a login shell
    > > created which is necessary to trigger profile initialization.
    >
    > Although it's annoying that this is the way *dm work it is the only
    > sensible way to do it (at least that I've heard!)
    >
    > Think of this: The display manager is in essence a series of shell
    > scripts with a fancy front-end. Now each of these shell scripts must use
    > a certain shell (bash, sh, csh, tcsh, ksh, zsh, the list goes on) and
    > each user on the system could potentially be using a different shell.
    >
    > Now do you have the display manager source every possible file that
    > should be sourced for each possible shell? Only source the files that
    > should be sourced for the shell that the login manager uses? Or do you
    > setup a system where by the users shell is determined and the
    > appropriate files sourced?

    Ok, I'll play along just for a moment -- let's assume that what you're
    saying is true. Then we are faced with two choices:

      A) Choose bash and screw sh, csh, tcsh, or whatever-sh users
      B) Do nothing and continue to screw everybody

    If we had a vote I think I would put my paycheck on A. If someone is
    running something other than the default shell they shouldn't have a
    problem hacking their own profile. But they don't need to ...

    > I hope if you think about it you'll realise that it is highly
    > non-trivial to implement a system where no matter which shell the user
    > uses the dm will act in the same way.
    >
    > For instance if the dm uses a bash login shell and I have two users on
    > the system one using tcsh and one using bash. Then the bash user would
    > have his login files sourced and the tcsh user would not

    I'm not suggesting that you manually source any files. The login shell
    automatically does that for you.

    Look, conceptually what needs to be done is simple. The purpose of the
    login option of a shell is to say "Hey, I'm logging in, initialize my
    environment." Subsequent shells do not use the login option which is
    to mean "Hey, I've already initialized my environment so don't bother
    to do it again. I just want another shell, inherit the environment from
    the parent."

    So all we have to do is detect when a user is logging in and exec their
    default shell with the login option. Debian does that when you ssh in
    or login on the console but not when you login with X.

    Where would we do that? Well let's review the process. Let's say your
    using gdm (but it's very similar for each login manager). Gdm calls
    scripts to be executed by root like /etc/X11/gdm/Init/Default for calling
    xmodmap, setting kbdrate, or /etc/X11/gdm/PostSession/Default mounting
    a home drive, etc. Then it switches to the user with setuid and calls
    scripts to be executed as the user to like /etc/X11/gdm/Xsession which
    calls /etc/X11/profile.d/ (or whatever it's called) which eventually
    exec's the session manager like say /usr/bin/wmaker possibly via
    ~/.xsession. Now if we exec the session manager at the very end we don't
    have a lot of choices. We have to launch our login shell there.

    Now I'm on a RH 7.3 system right now and I've never had this profile
    issue on RH systems so if I look at their scripts I see:

    #!/bin/bash

    ... lots of stuff ...

    # otherwise, take default action
    if [ -x "$HOME/.xsession" ]; then
        exec -l $SHELL -c "$HOME/.xsession"

    There are a lot of other lines that look like this but this one
    illustrates quite clearly how RH handles this. I'm not terribly familiar
    with exec options of bash but I'm willing to bet it has something to do
    with the login option or has the equivalent effect.

    You guys really should fix this problem. It's quite a wart.

    Mike 

    -- 
Greedo shoots first? Not in my Star Wars.
-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Zenaan Harkness: "Re: getting X standard background with metacity"

    Relevant Pages