Incomplete desktop when startx called outside of user home, v 4.7 and others

[cpoakes]

If startx is called outside of the user's home directory, X will start up a desktop without wallpaper, wbar or .X.d services.  The user sees a black screen and only the menus are accessible.

The cause stems from either the .xinitrc and/or .xsessionrc, as both make crucial tests and call executables from the "." current directory.  Aside from the failure to start essential services, this is a potential though unlikely (given our user community) entry point for trojan horses.

The HOME environment variable could be used in place of "."  Attached are .xinitrc and .xsession, candidate replacements using $HOME that have cured my problem.

[gerald_clark]

~ would be more conventional than $HOME.

[cpoakes]

Interesting note.  Either is fine by me if TC has a style guide for such things, just as long as it works!

I use $HOME over ~ as a personal safeguard.  I have encountered shells in embedded systems (pre-ash busybox) that didn't handle the tilde breaking scripts imported from elsewhere.  There are interpreted languages (python) that don't handle the tilde transparently (you must run the string through a function).  The new Debian Almquist shell (dash) will not interpret ~ in a PATH (but will elsewhere).   And in languages where ~ is an operator (perl et al), spelling out HOME is more explicit.  I don't consider the four extra key strokes much of a penalty for knowing I am not making one of these mistakes.  I might think differently if I wasn't a touch typist. 

[tinypoodle]

If startx is called outside of the user's home directory, X will start up a desktop without wallpaper, wbar or .X.d services.  The user sees a black screen and only the menus are accessible.

As far as I understand, .X.d is not designed for the use of starting any services.

The cause stems from either the .xinitrc and/or .xsessionrc, as both make crucial tests and call executables from the "." current directory.  Aside from the failure to start essential services, this is a potential though unlikely (given our user community) entry point for trojan horses.

How exactly?

[cpoakes]

Hey TinyPoodle, thanks.  You are absolutely right, I mispoke - mistakes were  made.  <retraction>Absolutely no system service or xserver is ever started from .X.d; only scripts starting X applications are found there. If system services were involved, it would be a serious problem - but they are not.</retraction> 

The entry point?  If I can induce you or another user to install a malicious file named .setbackground or .mouse_config in a commonly visited directory, I have created a trojan horse.  Anytime startx is executed in that directory, the trojan horse will be running with that user's permissions. Convincing a user to install such would be a feat of social engineering, and as I said, a potential though unlikely situation.  I mention the risk because it is similar to including "." in your PATH. 

My primary concern is not security; I just want startx to start correctly from anywhere and assume others would appreciate it too. 

[roberts]

Xlibs.tcz for 4.x and 5.x classic updated.
Xtc for dCore ports, 5.x and armv7 updated.

Note: Since .xsession ( .xinit for dCore) is in your home directory therefore likely in your backup.
Compare with /etc/skel and adjust as needed.