After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 127780 - gdmflexiserver --xnest can not work.
gdmflexiserver --xnest can not work.
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.4.4.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2003-11-24 02:57 UTC by James Su
Modified: 2003-12-20 00:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4



Description James Su 2003-11-24 02:57:11 UTC
Hi,
  When I tried to use gdmflexiserver --xnest, the current session exited
immediatly instead of opening a Xnest window.

  I'm using XFree86 4.3.0, kernel 2.6.0 gdm 2.4.4.5

Regards
Comment 1 Tom McLaughlin 2003-12-19 06:36:56 UTC
When trying to run version 2.4.4.5 `gdmflexiserver` or `gdmflexiserver
-xnest` with gnome 2.4.1 I either fail to get a new screen or XFree86
crashes. 

When I run `gdmflexiserver` the monitor flickers like it is taking me
to a new screen but the monitor stays dark.  I have to ctrl+alt+f9
back to my original display.  If I run `gdmflexiserver -xnest` then
XFree86 and gdm actually crash and drop me to a console.  Using
`gdmflexiserver -xnest` also produces the following errors.

/var/log/messages:
Dec 18 21:34:56 compass gdm[57837]: GDM file gdm.c: line 2852
(N/A):Cannot run setegid to 92

(92 is the id for gdm)


Last message in XFree86 log:
Fatal server error:
xf86OpenConsole: VT_SETMODE VT_PROCESS failed


I did not have this problem in gnome 2.4.0 and this machine's current
incarnation never had gnome 2.4.0 installed since I first thought this
was a problem with the FreeBSD port upgrade and something from the old
port conflicting with the new port.


I see that the gdm binaries are not setgid and are owned by root.  I
can run both commands fine if I am logged into gnome as root which
leads me to believe that this is a permission problem.

[tom@compass tom]$ ls -al /usr/X11R6/bin/|grep gdm
-r-xr-xr-x   1 root  wheel       264 Dec 15 00:41 gdm*
-r-xr-xr-x   1 root  wheel    215916 Dec 15 00:41 gdm-binary*
lrwxr-xr-x   1 root  wheel        15 Dec 15 00:41
gdmXnest@->gdmXnestchooser
-r-xr-xr-x   1 root  wheel     43048 Dec 15 00:41 gdmXnestchooser*
-r-xr-xr-x   1 root  wheel     69568 Dec 15 00:41 gdmchooser*
-r-xr-xr-x   1 root  wheel     36584 Dec 15 00:41 gdmflexiserver*
-r-xr-xr-x   1 root  wheel    130392 Dec 15 00:41 gdmgreeter*
-r-xr-xr-x   1 root  wheel    102804 Dec 15 00:41 gdmlogin*
-r-xr-xr-x   1 root  wheel     30592 Dec 15 00:41 gdmphotosetup*
-r-xr-xr-x   1 root  wheel     69960 Dec 15 00:41 gdmsetup*
-r-xr-xr-x   1 root  wheel      1664 Dec 15 00:41 gdmthemetester*


The following was suggested on the freebsd-gnome@freebsd.org:

Known bug: http://bugzilla.gnome.org/show_bug.cgi?id=127780.  I think
this has to do with the following commit:

Thu Sep 25 11:23:24 2003  George Lebl <jirka@5z.com>                 
                                                                     
* daemon/errorgui.c, daemon/slave.c: be even analer (is that a word?)
about the setuid stuff here (it can't actually fail, but just in case,
we're being paranoid)  Also reset the environment and desetuid for the
setup program even though that's not really needed.


System info:
[tom@compass tom]$ uname -srm
FreeBSD 4.9-RELEASE-p1 i386

Gnome info:
[tom@compass tom]$ pkg_info |grep gnome2
gnome2-2.4.1

XFree86 Server version info:
[tom@compass tom]$ pkg_info |grep Server
XFree86-FontServer-4.3.0_3 XFree86-4 font server
XFree86-NestServer-4.3.0_4 XFree86-4 nested X server
XFree86-Server-4.3.99.15 XFree86-4 X server and related programs
XFree86-VirtualFramebufferServer-4.3.0_4 XFree86-4 virtual framebuffer
server
Comment 2 George Lebl 2003-12-20 00:38:33 UTC
Yes you are correct.  Fixing in HEAD and gnome-2-4 branch.  Doh!. 
It's a good catch though since that setegid would have been useless
otherwise and provided little security of mind (the group should in
fact be GdmGroupId anyway ...)