When I last logged in on 2013-08-27, evenrything was OK. But when
I came back at my office on 2013-08-30, fvwm was no longer reading
my config file. After some search, I could see that .xsession-errors
contained:

/etc/gdm3/Xsession: Beginning session setup...
/home/vlefevre/.Xresources:1:18: warning: missing terminating ' character [enabled by default]
 ! Vincent Lef�vre's .Xresources
                  ^
localuser:vlefevre being added to access control list
openConnection: connect: No such file or directory
cannot connect to brltty at :0

On another machine, with very similar config, I get:

/etc/gdm3/Xsession: Beginning session setup...
/home/vinc17/.Xresources:1:18: warning: missing terminating ' character [enabled by default]
 ! Vincent Lef�vre's .Xresources
                  ^
localuser:vinc17 being added to access control list
/home/vinc17/.xsession (.xinitrc) started
[...]

The "/home/vinc17/.xsession (.xinitrc) started" line is output
by my .xsession script. This means that on the first machine,
this file is no longer executed.

Then I looked at the /var/log/syslog* files, and I could see a
difference, e.g. before I left:

Aug 26 13:13:40 ypig gdm3][12024]: DEBUG(+): GdmSessionWorker: start program: /etc/gdm3/Xsession "default"

Aug 27 12:01:33 ypig gdm3][24527]: DEBUG(+): GdmSessionWorker: start program: /etc/gdm3/Xsession "default"

and when I came back:

Aug 30 17:07:39 ypig gdm3][22605]: DEBUG(+): GdmSessionWorker: start program: /etc/gdm3/Xsession "fvwm2"

Aug 30 17:10:41 ypig gdm3][31341]: DEBUG(+): GdmSessionWorker: start program: /etc/gdm3/Xsession "fvwm2"

Aug 30 17:11:11 ypig gdm3][32473]: DEBUG(+): GdmSessionWorker: start program: /etc/gdm3/Xsession "fvwm2"

4 config files under /etc/X11 were changed during package upgrades
after my login on 2013-08-27:

Am 31.08.2013 02:09, schrieb Vincent Lefevre:

I fail to see the justitification for this severity, can you elaborate?

This looks like a bug in your users .Xressources script.

I still fail to see the bug in gdm3 here.

I can no longer use the machine normally. This problem makes things
worse as the default fvwm2 config is broken: the proposed "Xterm"
doesn't support non-ASCII characters, with display corruption when
using "screen" (at least remotely via SSH).

No, this is just a harmless warning due to a bug in xrdb
(bug 443537).

[...]

Well, the behavior has changed, making the machine hardly usable,
while I didn't change anything in my config!

Am 31.08.2013 09:49, schrieb Vincent Lefevre:


The gdm3 package hasn't changed for quite a while, so I fail to see how
the behaviour of the gdm3 package should have changed?

It's more likely that a local modification or another package changed
something on your system.

A bug?

I don't see what could have changed. The change of some config files
under /etc/X11 was due to the upgrade of "menu", but I don't see this
could affect gdm3.

It seems that something occurred with the machine yesterday at around
15:00 (this is where fvwm appears for the first time), while I wasn't
using the machine. According to syslog information, someone attempted
to log under my username (only normal user of the machine), but
*didn't succeed*. So, this doesn't explain why gdm3 no longer starts
my .xsession script.

I've found the problem: someone has apparently changed my next session
while I wasn't here. This is some kind of security problem: someone
has more rights that he should have.

And if one never changes the session, one doesn't look at the
information, so that one doesn't necessarily know what the problem
is, and something just looks wrong with the machine (in my case,
without looking at log files, it just seemed that fvwm couldn't
read my config file).

Hi,

Le Mon, 2 Sep 2013 11:02:11 +0200,
Vincent Lefevre <vincent@vinc17.net> a écrit :

So if I understood correctly:

1) A "rogue" user has selected your user in the list and then changed
   your session to something else.
2) When you arrived in front of the screen you saw that your user was
   already selected and then you just typed your password
3) You were logged in using the wrong session.

Is that correct?

Cheers

Laurent Bigonville

I think that I cancelled first by typing Enter (i.e. an incorrect
password).

But, FYI, my user is selected by default as this is the only user
of the machine.

severity 721388 normal
thanks

Le Mon, 9 Sep 2013 19:22:29 +0200,
Vincent Lefevre <vincent@vinc17.net> a écrit :

I tried to reproduce this on a machine running GDM 3.8 and I definitely
cannot reproduce this. To save the default session of a user you really
need to enter the password of this user, and as soon as you are hitting
escape or enter with a wrong password, the session of the user is reset
to the saved one.

I guess that adding a timeout to un-select the user (return from the
screen where you need to enter the password to the one (main) were you
select the user) could mitigate this issue. I'll open an upstream bug
for this.

Cheers

Laurent Bigonville

With gdm 3.4, the session name is not reset. And this is reproducible
here. There might be a change in gdm 3.8.

Thanks. More comments there...

Control: tags -1 - fixed-upstream

The upstream bug was closed without being fixed.