Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
... introduced when we migrated to the xorg-server 1.19.x code base in TurboVNC 2.2 (a661ed1). - Use dup() to obtain a free file descriptor for the inetd socket rather than statically assigning FD 3. Otherwise, if Xvnc calls a function (such as getpwuid()) that invokes libnss_sss prior to calling ddxProcessArgument(), then libnss_sss will obtain the first free file descriptor (3) for its own purposes, ddxProcessArgument() will clobber that file descriptor, and hilarity will ensue. TurboVNC doesn't currently make an early call to a function that invokes libnss_sss, but referring to TigerVNC/tigervnc#1709, TigerVNC does. It is possible that we will do so in the future. Based on: TigerVNC/tigervnc@7a9773a - Explicitly redirect stderr (FD 2) to /dev/null rather than simply closing it. Otherwise, OsInit() (more specifically ospoll_create()) will obtain the first free file descriptor (2) to use for polling, then it will check whether FD 2 (which it assumes is still stderr) is writable. Since polling file descriptors aren't writable, OsInit() will redirect FD 2 to /dev/null, thus breaking the polling subsystem. (Symptomatically, that caused the TurboVNC Server, when used with the -inetd option, to do nothing when a VNC viewer connected.) Based on: TigerVNC/tigervnc@712cf86 - Move the inetd RFB connection code from ProcessInputEvents() to the end of InitInput(), since ProcessInputEvents() isn't usually called until/unless a window manager is started. (Symptomatically, that also caused the TurboVNC Server, when used with the -inetd option, to do nothing when a VNC viewer connected.) Probably fixes #303
- Loading branch information