Comment 8 for bug 35217

There already is reserved space (for root, and gdm is launched as root) however this space can be filled by root itself using e.g. apt or pbuilder. Reserving space for a single program might be interesting but would require kernel modification.

I have a simpler solution in mind, but I am still waiting to find the time to try this :) The idea is to make gdm write _all_ of its temporary files, which are small, on a ramfs. Mounting a ramfs is really easy, however I didn't have the time to modify gdm in order to write all files in a user-defined directory. The next step would then be to check how many programs of the default gnome session crash if disk space is exhausted and perhaps use the same trick (even if I suspect non-root applications writing to a temporary filesystem could lead to denial of service attacks).

In "man mount" one can find

===
Mount options for ramfs
       Ramfs is a memory based filesystem. Mount it and you have it. Unmount
       it and it is gone. Present since Linux 2.3.99pre4. There are no mount
       options.

===

Actually, it is not necessary to use a ramfs. A loopback ext2 mount on a fixed-size file would probably be easier, and raise less security problems. The fixed-size file would act as the space "reserved for gdm". A temporary directory for the logged in user could be created, even with quotas, to allow writing temporary sockets to all session applications.

In both cases, the main problem remains, to make gdm write into a precise directory and not where she wants, i.e. in /tmp. First of all, let's see what are the files that gdm absolutely needs to write. Quoting from the upstream bug, the files gdm writes at login are:

===
+ /tmp/.gdm_socket for the GDM daemon and GUI program to talk to each other
  properly. Without the socket being setup, GDM probably would still work
  though the GUI program wouldn't be able to access the config file and would
  instead revert to the compiled-in defaults (e.g. your theming would probably
  be wrong). Features that require the socket to be working (such as
  automatic/timed login or any gdmflexiserver --commands) would also not work.
  Perhaps moving the socket to /var/tmp might make it less likely you'd have
  problems here?

+ GDM uses /tmp for the fallback Xauth key directory if the normal xauth
  directory (UserAuthDir in the GDM configuraiton) is also full. If GDM can't
  write xauth files, then it probably wouldn't let the user login. If both
  UserAuthDir and /tmp are full, this could be a problem with GDM not allowing
  users to log in at all.

+ /tmp/.ICE-unix, /tmp/.X11-lock, and /tmp/.X11-unix are also used. Not sure
  how GDM will break if it couldn't write these files. I'm guessing this might
  be the problem that causes GDM to fail to allow login when /tmp is full.

+ If the user's $HOME is full, it will put the .xsession-errors file in /tmp
  instead. Probably not a big deal if these don't get written, though I'm not
  sure what GDM does if it can't write them.
===

Then, I e-mailed Brian Cameron directly, asking him where are the locations of all these files decided in the code, this was the reply:

===
You'ld need to edit the daemon/gdm.h file and modify this line:

#define GDM_SUP_SOCKET "/tmp/.gdm_socket"

Might be nice if this could be configured in the GDM configuration
file rather than being hardcoded in the code. If you find that fixing
this corrects the problems with GDM not working when /tmp is full, then
I'd be happy to accept a patch that allows people to configure this.
Also perhaps adding some user docs to explain how you can use ad-hoc
ramfs to avoid GDM problems when /tmp is full, etc.
===

That's all :)