Redesign login shell use in session scripts

[Vogtinator]

See #1768 (comment)

New approach, which does not suffer from the xprofile behaviour change:

Avoid the re-import of variables into sh by using the user's login shell
to invoke the session.

For the wayland-session script it's straightforward: Just exec the session
command directly within the login shell.

For the Xsession script it's a bit more complex: The login shell environment
has to be loaded first, then the xprofile files, so that they can overwrite
the login shell environment. To achieve this, the script runs in two stages:
The first uses the login shell to exec the second stage, which then reads
xprofile and execs the session.

Draft because only tested outside of a system installation so far.

[Vogtinator]

Draft because it's late here and so I didn't test it, but wanted to get it published anyway to show the idea.

Works as expected. Tested with bash, fish, csh and zsh.

bash: /etc/profile is sourced.

fish: /etc/profile is sourced, fish.config is also read.

csh: .cshrc is read, but not /etc/profile (same as before)

zsh: /etc/profile is sourced, .zprofile is also read.

[arrowd]

If I understand it right, the environment from /etc/profile now overrides the environment set in ~/.xsession? Would that be a POLA violation?

[Vogtinator]

If I understand it right, the environment from /etc/profile now overrides the environment set in ~/.xsession? Would that be a POLA violation?

I think so.

Might be possible to just source it unconditionally at the top and assume it won't be sourced again by sh compatible shells through some mechanism like $PROFILEREAD.

[arrowd]

We don't seem to have PROFILEREAD anywhere on FreeBSD. Is this some sort of well-known env var?

[Vogtinator]

We don't seem to have PROFILEREAD anywhere on FreeBSD. Is this some sort of well-known env var?

I don't know. The /etc/profile I have here does

#
# Avoid overwriting user settings if called twice
#
if test -z "$PROFILEREAD" ; then
    readonly PROFILEREAD=true
    export PROFILEREAD
fi

and surrounds most code with test -z "$PROFILEREAD

[arrowd]

Might be possible to just source it unconditionally at the top and assume it won't be sourced again by sh compatible shells

This won't work on FreeBSD, unfortunately.

I'm confused, why do we try to pull env from bash/fish/zsh at all if now we call $SHELL $@ instead of exec $@?

[CoelacanthusHex]

Draft because it's late here and so I didn't test it, but wanted to get it published anyway to show the idea.

Works as expected. Tested with bash, fish, csh and zsh.

bash: /etc/profile is sourced.

fish: /etc/profile is sourced, fish.config is also read.

csh: .cshrc is read, but not /etc/profile (same as before)

zsh: /etc/profile is sourced, .zprofile is also read.

As zsh doc said, if zsh is invoked with 'zsh', it will not source /etc/profile but /etc/zprofile. Some distro land a /etc/zprofile with emulate sh -c 'source /etc/profile'.
If zsh is invoked with 'sh', it will has same behavior as 'sh'.

[Vogtinator]

As zsh doc said, if zsh is invoked with 'zsh', it will not source /etc/profile but /etc/zprofile. Some distro land a /etc/zprofile with emulate sh -c 'source /etc/profile'. If zsh is invoked with 'sh', it will has same behavior as 'sh'.

That means, if we source /etc/profile explicitly and the distro also sources it from /etc/zprofile, it ends up getting sourced twice (which may or may not be an issue). If we don't (like now), /etc/profile might not get sourced at all.

[HerrNaN]

Tried to incorporate this in my Fedora Sericea build but to no avail, then I saw that the Fedora tests are not passing. Is there any work planned to get this working and into the main branch?

[Vogtinator]

Tried to incorporate this in my Fedora Sericea build but to no avail, then I saw that the Fedora tests are not passing. Is there any work planned to get this working and into the main branch?

The Fedora CI failures are for Fedora reasons, not SDDM reasons.

[HerrNaN]

Tried to incorporate this in my Fedora Sericea build but to no avail, then I saw that the Fedora tests are not passing. Is there any work planned to get this working and into the main branch?

The Fedora CI failures are for Fedora reasons, not SDDM reasons.

I see, I haven't been able to pin-point exactly what those are, do you know?

[Vogtinator]

Tried to incorporate this in my Fedora Sericea build but to no avail, then I saw that the Fedora tests are not passing. Is there any work planned to get this working and into the main branch?

The Fedora CI failures are for Fedora reasons, not SDDM reasons.

I see, I haven't been able to pin-point exactly what those are, do you know?

On clang internal compiler errors, i.e. compiler bugs. The current failures on develop are new, the CI workflow needs to be adjusted after fedora switched sddm to Qt 6 (I assume).

[Vogtinator]

I implemented a different approach which should work everywhere without noticable behaviour changes. Needs testing.

[arrowd]

It looks good to me, but I didn't test it at the runtime.

[Vogtinator]

Tested with fish and bash, works.

[Pogogo007]

Any activity? I had a bug that caused sddm to fail to load any session while using fish and this mr completly fixed the issue

[Vogtinator]

It's ready for merge, just needs approval from a maintainer.

[bernhardreiter]

It's ready for merge, just needs approval from a maintainer.

Meanwhile you could sync it with the base branch.

Thanks for having put work in towards a solution!

[jfroy]

For what it's worth, I was really puzzled why sddm failed to create sessions on my system until I found and tested this PR. It does indeed fix the problem if your shell is fish.