Ubuntu
xorg-server package

server fails to start up if TMPDIR is set to something on a different filesystem from /var/lib/xkb

Bug #972324 reported by Colin Watson
76
This bug affects 14 people
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

If TMPDIR is set to something on a different filesystem from /var/lib/xkb, then the X server fails to start up as follows:

  [xkb] Can't rename /tmp/tmp.qHzEh1iHUk/dsc0-build/tmpdir/fileAfodkU to /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Invalid cross-device link
  (EE) XKB: Couldn't compile keymap
  (EE) XKB: Failed to load keymap. Loading default keymap instead.
  [xkb] Can't rename /tmp/tmp.qHzEh1iHUk/dsc0-build/tmpdir/fileF2rYOh to /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm, error: Invalid cross-device link
  (EE) XKB: Couldn't compile keymap
  XKB: Failed to compile keymap

A simple way to reproduce this is to start a fresh schroot (preferably with overlayfs or LVM snapshots so that you can start from scratch trivially), make sure no /var/lib/xkb/server-*.xkm files exist, and run 'TMPDIR=/tmp xvfb-run sh'.

This is because XkbDDXCompileKeymapByNames uses tempnam(xkm_output_dir, NULL) to create a temporary file. As documented, tempnam(3) prefers TMPDIR over the directory argument if TMPDIR is set. Perhaps this code should use something based on mkstemp(3) instead, which would permit finer-grained control.

This makes it tedious to run DEP-8 test suites that require Xvfb, because adt-run sets TMPDIR.

Tags: precise
Revision history for this message
Colin Watson (cjwatson) wrote :

This appears to be caused by an Ubuntu-specific patch which we borrowed from Moblin.

Bryce Harrington (bryce)
tags: added: precise
Changed in xorg-server (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
David Lichteblau (david-lichteblau) wrote :

There is a second issue with the failing rename operation that this bug report is referring to:

The target file $TMPDIR/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm is apparently shared between servers and never gets deleted. So you cannot start multiple X servers as different users, because the second server/user will attempt to mv over a file owned by a different user account.

While the main X server usually runs as root, and isn't affected by the bug, you cannot currently start Xvfb processes from multiple user accounts, for example.

Shouldn't the file (assuming it is needed at all) not have a $DISPLAY-specific name, and get deleted when the X server shuts down at the latest?

Revision history for this message
Alec Warner (antarus) wrote :

There may also exist a security issue, where user alice creates specially crafted keymaps in /tmp/$HASH.xkm and then user bob launched X and the X system tries to re-use alice's evil keymap.

I'm unsure if the X server keymap loader is exploitable, but it is likely that keymaps should not be shared between users in this way (if nothing else, alice can upload a wacky keymap and bob may not know how to turn it off.)

-A

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.