0

I have a small office with 5 desktops and a server, all of them running on Debian. I have just upgraded the clients to Stretch and see only 1 error in the journal that bothers me:

gnome-settings-[939]: failed to create profile from EDID data: failed to save ICC file: Error opening file ‘/var/data/users/Debian-gdm/icc/edid-93ed9b01fe8febb07668e99b557191e9.icc’: Access denied
gnome-settings-[939]: failed to create profile from EDID data: failed to save ICC file: Error opening file ‘/var/data/users/Debian-gdm/icc/edid-93ed9b01fe8febb07668e99b557191e9.icc’: Access denied
gnome-settings-[939]: failed to set screen _ICC_PROFILE: Opening file ‘/var/data/users/vincent/icc/edid-93ed9b01fe8febb07668e99b557191e9.icc’ failed: Access denied

As our users $HOME folders are mounted through NFS, I have made sure that all $XDG_DATA and $XDG_CACHE (at least for regular users) are stored locally on the client. Back in 2014 I had found a manual to do it like this:

In /etc/profile.d/xdg_dirs.sh:

if [ "$USER" == "root" ]; then
  unset XDG_CACHE_HOME
  unset XDG_DATA_HOME
else
  test -d $XDG_CACHE_HOME || mkdir -p $XDG_CACHE_HOME
  test -d $XDG_DATA_HOME || mkdir -p $XDG_DATA_HOME
fi

In /etc/security/pam_env.conf:

XDG_CACHE_HOME DEFAULT="/var/cache/users/@{PAM_USER}"
XDG_DATA_HOME  DEFAULT="/var/data/users/@{PAM_USER}"

I'm pretty sure this has messed up the correct permissions for the Debian-gdm user, but I don't know how to solve it. I tried creating the dir and giving r+w permissions to both Debian-gdm and the default user-groups, but this didn't work. I also tried exclusing the Debian-gdm user from the above script by adding:

if [ "$USER" == "root" ] || [ "$USER" == "Debian-gdm" ]; then

, but that didn't work as well.

Any thoughts?

2 Answers 2

1

I believe the main problem here is that /etc/profile.d/xdg_dirs.sh is not sourced when starting gdm since it's now using wayland and not X (Xsession script is not started anymore)

IMHO, you shouldn't mangle with these variables. The home of the Debian-gdm user is stored in /var/lib/gdm3 which should already be local on your client.

What I would do is to modify /etc/pam.d/gdm-launch-environment, in there you have two calls to pam_env.so on the first call, set conffile=to /dev/null. That will prevent the pam module to read the /etc/security/pam_env.conffile a keep the environment untouched.

An other solution is to try to start gdm using X instead of Wayland, set WaylandEnable=false in /etc/gdm3/daemon.conf

6
  • Thank you for sending me in the right direction. I have now read up on these changes related to the switch from X to Wayland, and I am reluctant to make changes that would potentially produce erratic behavior if a user were to chose 'Gnome on Wayland' or 'Gnome on X' in the GDM option menu. Therefore, I looked what was wrong in the current files. I inserted the variable-setting into the xdg_dirs.sh file, expanded the if-branch as I detailed in the question and removed the pam_env.conf file. This seems to solve it (and it also discloses that Gnome on Debian Stretch does source X vars)
    – zenlord
    Commented Dec 31, 2017 at 16:02
  • Ok, disregard my previous comment, as it didn't work out. If you change your answer to read 'gdm-password' instead of 'gdm-launch-environment' and hint at 'user_readenv=1' while you're at it, I'll approve it as the correct answer
    – zenlord
    Commented Dec 31, 2017 at 18:34
  • My initial change to the pam service config was meant to avoid changing XDG_CACHE_HOME and XDG_DATA_HOME for the gdm processes. Here you are requiring all your user to have a config file in their home directory and that this file is correct as well.
    – Bigon
    Commented Jan 2, 2018 at 8:49
  • Ah, I see. Your solution is to exclude the Debian-gdm user from changing those dirs, whereas my solution is to explicitly include all non-system users manually. I'll experiment with your solution, as it takes away the burden to manage a file per user. Thx!
    – zenlord
    Commented Jan 2, 2018 at 8:55
  • 1
    Quickly looking at the pam code, I think you need to pass conffile=/dev/null to the two calls to pam_env in /etc/pam.d/gdm-launch-environment, not only the first one
    – Bigon
    Commented Jan 2, 2018 at 9:01
0

Since asking this question, I have upgraded all systems from Stretch to Buster and I am in the middle of upgrading to Bullseye. I went with @Bigon 's answer for Stretch and Buster, but am returning to the initial solution because of an error that pam_env.so kept spawning. I did not ever witness any issues, so the error is not harmful at all.

For future visitors, if your user's $HOME is served from NFS, it is useful to store the user's cache locally, which is why it is useful to set the XDG_CACHE_HOME environment variable for your users with an $UID>=2000 via /etc/profile, e.g.:

if ((`id -u`>=2000)); then
  umask 0007
  USER=$(id -un)
  if [[ !-d "/var/cache/users/$USER" ]]; then
    mkdir "/var/cache/users/$USER"
    chown "$USER" "/var/cache/users/$USER"
  fi
  XDG_CACHE_HOME=/var/cache/users/$USER
  export XDG_CACHE_HOME
  NSS_SDB_USE_CACHE=yes
  export NSS_SDB_USE_CACHE
fi

This solution stops errors with system users such as root and Debian-gdm, and it works independently of the session manager that the user is using. I have deleted all references to pam_env.so in my setup.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .