Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames

Vincent Danjean-4
Package: xscreensaver
Version: 5.42+dfsg1-1
Severity: normal

  Hi,

  I run xscreensaver (with xfce4) on machines that use SSSD
to managed its users. There are several source of authentification
(as allowed by SSSD) but the main one (and default one) is to
authenticate against an AD (windows kind of ldap/kerberos).
  The important thing is that user names (ie logins) are of the
form name@domain

  When launching xscreensaver-demo, I always got the following
message (sorry, its in French):
===================
xscreensaver-demo est lancé par l'utilisateur «name@domain» sur la machine «myhostname».
Cependant le xscreensaver gérant l'écran «:0.0»
est lancé par l'utilisateur «name»  sur la machine «domain@myhostname».

Comme ce sont des utilisateurs différents, ils ne vont pas lire/écrire
le même fichier «~/.xscreensaver», donc xscreensaver-demo ne fonctionnera
pas correctement.

Vous devez soit relancer xscreensaver-demo en tant que «name», soit relancer
xscreensaver en tant que «name@domain».

Relancer le démon xscreensaver maintenant ?

Annuler / Valider
==================
[approximate translation:]
xscreensaver-demo is launched by the «name@domain» user on the «myhostname» machine.
However, the xscreensaver managing the screen «:0.0»
is launched by the «name» user on the «domain@myhostname» machine.

As these are two different users, they won't read/write
the same «~/.xscreensaver» file, so xscreensaver-demo won't work
correctly.

You must either restart xscreensaver-demo as «name», or restart
xscreensaver as «name@domain».

Restart xscreensaver daemon now?

Cancel / Validate
==================

Using "Annuler" (ie cancel) or "Valider" (validate) leads to the
same effect: I can manipulate the demo options through xscreensaver-demo
in any cases.

  I suspect the message is due to the fact that xscreensaver(-demo?)
stores the login and the machine name under the form login@machine
but fails to correctly parse such string when login contains a '@'
character, as this is the case here.

  Regards,
    Vincent

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xscreensaver depends on:
ii  libatk1.0-0          2.30.0-2
ii  libc6                2.28-10
ii  libcairo2            1.16.0-4
ii  libfontconfig1       2.13.1-2
ii  libfreetype6         2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglade2-0          1:2.6.4-2+b1
ii  libglib2.0-0         2.58.3-2+deb10u2
ii  libgtk2.0-0          2.24.32-3
ii  libice6              2:1.0.9-2
ii  libpam0g             1.3.1-5
ii  libpango-1.0-0       1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-0    1.42.4-7~deb10u1
ii  libsm6               2:1.2.3-1
ii  libx11-6             2:1.6.7-1
ii  libxext6             2:1.3.3-1+b2
ii  libxi6               2:1.7.9-1
ii  libxinerama1         2:1.1.4-2
ii  libxml2              2.9.4+dfsg1-7+b3
ii  libxmu6              2:1.1.2-2+b3
ii  libxrandr2           2:1.5.1-1
ii  libxrender1          1:0.9.10-1
ii  libxt6               1:1.1.5-1+b3
ii  libxxf86vm1          1:1.1.4-1+b2
ii  xscreensaver-data    5.42+dfsg1-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:1.5.2-2+b1
ii  perl                  5.28.1-6
ii  wamerican [wordlist]  2018.04.16-1
ii  wfrench [wordlist]    1.2.4-1

Versions of packages xscreensaver suggests:
ii  firefox-esr [www-browser]  68.4.1esr-1~deb10u1
pn  fortune                    <none>
ii  gdm3                       3.30.2-3
ii  konqueror [www-browser]    4:18.12.0-1
ii  lynx [www-browser]         2.8.9rel.1-3
pn  qcam | streamer            <none>
ii  w3m [www-browser]          0.5.3-37
pn  xdaliclock                 <none>
pn  xfishtank                  <none>
pn  xscreensaver-data-extra    <none>
pn  xscreensaver-gl            <none>
pn  xscreensaver-gl-extra      <none>

-- no debconf information
Reply | Threaded
Open this post in threaded view
|

Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames

Tormod Volden-3
Hi Vincent,

Thanks for your report. Yes, I understand it from the messages that on
your machines getpwuid() returns a username including this "@domain"
part, but the server_xscreensaver_version() which queries the server,
strips away all "@" parts (I don't even know if XGetWindowProperty()
returns the @domain part here).

First, I am not familiar enough with SSSD to know if pw_name should
include the "@domain" part, but I will assume it for the following
suggestions, in preferred order:

1) if XGetWindowProperty() returns user@domain@host, this simple patch
could solve it by only stripping the last "@" part:

diff --git a/driver/remote.c b/driver/remote.c
index 83254e0..e409ebc 100644
--- a/driver/remote.c
+++ b/driver/remote.c
@@ -681,7 +681,7 @@ server_xscreensaver_version (Display *dpy,
            {
              char *o = 0, *p = 0, *c = 0;
              o = strchr ((char *) id, '(');
-             if (o) p = strchr (o, '@');
+             if (o) p = strrchr (o, '@');
              if (p) c = strchr (p, ')');
              if (c)
                {

2) in case XGetWindowProperty() doesn't return the "@domain" part,
canonicalize the username received via server_xscreensaver_version so
it should match the getpwuid() result:

diff --git a/driver/demo-Gtk.c b/driver/demo-Gtk.c
index da98c53..14f82c1 100644
--- a/driver/demo-Gtk.c
+++ b/driver/demo-Gtk.c
@@ -4477,6 +4477,17 @@ the_network_is_not_the_computer (state *s)

   server_xscreensaver_version (dpy, &rversion, &ruser, &rhost);

+  /* canonical name in case of directory service */
+  if (ruser)
+    {
+      const char *new_ruser = getpwnam(ruser)->pw_name;
+      if (new_ruser)
+        {
+          free(ruser);
+          ruser = strdup(new_ruser);
+        }
+    }
+
   /* Make a buffer that's big enough for a number of copies of all the
      strings, plus some. */
   msg = (char *) malloc (10 * ((rversion ? strlen(rversion) : 0

3) the hammer, strip away any "@" part in the getpwuid() result:

diff --git a/driver/demo-Gtk.c b/driver/demo-Gtk.c
index da98c53..d2c9b6a 100644
--- a/driver/demo-Gtk.c
+++ b/driver/demo-Gtk.c
@@ -4471,7 +4471,13 @@ the_network_is_not_the_computer (state *s)
 # endif /* !HAVE_UNAME && !VMS */

   if (p && p->pw_name)
-    luser = p->pw_name;
+    {
+      char *domain;
+      luser = p->pw_name;
+      domain = strchr(luser, '@');
+      if (domain)
+        *domain = '\0';
+    }
   else
     luser = "???";

@@ -4496,7 +4502,7 @@ the_network_is_not_the_computer (state *s)
          "on display \"%s\".  Launch it now?"),
            d);
     }
-  else if (p && ruser && *ruser && !!strcmp (ruser, p->pw_name))
+  else if (p && ruser && *ruser && !!strcmp (ruser, luser))
     {
       /* Warn that the two processes are running as different users.
        */


(Presenting all three just because I already have them, having jumped
on (3) then (2) before I had thought through it)

If you are willing to build and test, please try it on the latest
version from https://salsa.debian.org/debian/xscreensaver

Regards,
Tormod


On Wed, Apr 8, 2020 at 10:57 PM Vincent Danjean  wrote:
>
>   I run xscreensaver (with xfce4) on machines that use SSSD
> to managed its users. There are several source of authentification
> (as allowed by SSSD) but the main one (and default one) is to
> authenticate against an AD (windows kind of ldap/kerberos).
>   The important thing is that user names (ie logins) are of the
> form name@domain

>   I suspect the message is due to the fact that xscreensaver(-demo?)
> stores the login and the machine name under the form login@machine
> but fails to correctly parse such string when login contains a '@'
> character, as this is the case here.
>
>   Regards,
>     Vincent