[Bug 35217] Re: Unable to login when disk space is exhausted

[Vincenzo Ciancia]

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 :)

-- 
Unable to login when disk space is exhausted
https://launchpad.net/bugs/35217