>Sent: Sunday, January 19, 2020 at 1:02 AM
>From: "Ken Moffat via blfs-support" <[email protected]>
>To: "BLFS Support List" <[email protected]>
>Cc: "Ken Moffat" <[email protected]>
>Subject: Re: [blfs-support] GDM startup problem
>From: "Ken Moffat via blfs-support" <[email protected]>
>To: "BLFS Support List" <[email protected]>
>Cc: "Ken Moffat" <[email protected]>
>Subject: Re: [blfs-support] GDM startup problem
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.
> 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.
Good advice. Many thanks
Cliff
-- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
