On Sat, Jan 18, 2020 at 09:16:50PM +0100, Cliff McDiarmid via blfs-support wrote: > Hi > > The permissions from my working LFS(I've just restored it - again) > > > drwxrwx--T 6 gdm gdm 4096 Jan 18 20:00 . > drwxr-xr-x 31 root root 4096 Jul 10 2019 .. > drwx------ 5 gdm gdm 4096 Apr 14 2019 .cache > drwx------ 7 gdm gdm 4096 Apr 1 2019 .config > -rw------- 1 gdm gdm 16 Apr 1 2019 .esd_auth > -rw------- 1 gdm gdm 35172 Jan 18 20:00 .ICEauthority > drwxr-xr-x 3 root root 4096 Mar 17 2019 .local > drwx------ 3 gdm gdm 4096 Apr 1 2019 .nv > > It usually fails aftre several reboots > > Cliff >
So, if before you logout of gdm each time, root could ls -lR those directories, and the .config subdirectories, and also just before shutting down/rebooting (perhaps do _that_ from a tty) you might be able to notice a change when it next fails. Obviously, *check* the results of 'ls -lR' and adapt the switches and arguments to minimally get the relevant directories and files before starting to use it as a matter of course. Of course, sod's law says you'll usually remember to run that, but the one time you don't will be when things go wrong. At the moment we don't know if gdm is somehow managing to trash perms when you logout, or when you use gdm to poweroff|reboot|hibernate, or if something else entirely unrelated happens to do that. If the latter, think about what ran during the last successful session. Maybe a bad script under su or sudo, but maybe something worse (someone taking advantage of a vulnerability, but accidentally changing the ownership back to root:root and therefore causing gdm to fail). Seems unlikely, but I don't know who you are, what browser(s) you use, how up to date they are, what URLs you visit, what you run, whether or not you have other local human users. And no, I really don't want to know more about your setup, I'm just trying to point out what you might need to think about. For the moment it _looks_ like the perms are the normal problem, but we have no idea what you are running (beyond _some_ version of gdm, some version of systemd, and apparently the nvidia external kernel module). And if the perms do change, look at the whole system and compare it to the backup to see if anything else changed perms (binaries, libs, libexec). Of the "good" possibilities, either something in gdm, or in another regular daemon, has hit a bug, or perhaps a regular task (maybe cron-style) is doing the wrong thing. As I think I've said to you before: Good Luck - in this case I think you'll need it. -- The politics of wizardry were either very simple, and resolved by someone ceasing to breathe, or as complex as one ball of yarn in a room with three bright-eyed little kittens. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
