[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    xenodm man page's Xsession script doesn't reflect /etc/X11/xenodm/Xsession
From:       Laurence Tratt <laurie () tratt ! net>
Date:       2021-07-27 7:49:37
Message-ID: 20210727074937.uucjvgw4spidkjt4 () overdrive ! tratt ! net
[Download RAW message or body]

For some years I've had a seemingly odd problem where logging in via xenodm
did not respect my login class. I've tried repeatedly to work out why, and
until now always failed -- it turns out that my ~/.xsession file was not
marked as executable and this caused our Xsession to run it via /bin/sh.
This is ultimately an act of gross stupidity on my part, but I thought it
might be worth documenting how I'd managed not to fix this for so long.

Here's the relevant chunk of xenodm's default Xsession:

  # The startup script is not intended to have arguments.

  startup=$HOME/.xsession
  resources=$HOME/.Xresources

  if [ -s "$startup" ]; then
    if [ -x "$startup" ]; then
      "$startup"
    else
      /bin/sh "$startup"
    fi
  else
    ...
  fi

Notice that it runs ~/.xsession differently based on its executable
permission bits. This isn't documented anywhere and xenodm's man page
unintentionally threw me off the scent, partly because it's not very
OpenBSD-like.

The first mention of Xsession in xenodm's man page is vague (this should
have been a clue to me to read Xsession more carefully I now realise!):

  Then xenodm runs the Xsession script as the user.  This system session
  file may do some additional startup and typically runs the .xsession
  script in the user's home directory.  When the Xsession script exits, the
  session is over.

It's quite easy at that point not to realise that there is a section of the
man page later called "SESSION PROGRAM" which clears up some of that
vagueness. A forward link might be a good idea?

The "SESSION PROGRAM" section itself implicitly describes all possible
Xsession scripts rather than the one xenodm actually ships with. For
example:

  At most installations, Xsession should look in $HOME for a file .xsession,
  which contains commands that each user would like to use as a session.

An example Xsession script is then described:

  This example recognizes the special failsafe mode, specified in the
  translations in the Xresources file, to provide an escape from the
  ordinary session.  It also requires that the .xsession file be executable
  so we don't have to guess what shell it wants to use.

Of course, if I'd read that carefully I should have checked that my
~/.xsession file is executable. However, the example Xsession script in the
man page then contains this code:

  if [ -f "$startup" ]; then
    exec "$startup"
  else
    ...
  fi

i.e. it doesn't contain the "if ~/.xsession isn't executable, run it via
/bin/sh" part that xenodm's default Xsession does. It thus never occurred to
me to check whether my ~/.xsession is executable, because under the example
Xsession, it couldn't possibly run if it wasn't executable.

The reason I'm filing a bug report and not a patch is that I'm not really
sure if/what a fix for this might be. I am not sure if xenodm's man page is
structured as it is to keep it in sync with upstream, and I'm also not sure
if it's expected that people will actually change Xsession or not. Some
possible ideas are: tell people to read the source of
/etc/X11/xenodm/Xsession to; change the example Xsession to reflect what
xenodm's default Xsession does.


Laurie

[prev in list] [next in list] [prev in thread] [next in thread]