After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 144473 - GDM could provide meaningful error when /tmp permissions are incorrect
GDM could provide meaningful error when /tmp permissions are incorrect
Status: RESOLVED WONTFIX
Product: gdm
Classification: Core
Component: general
2.6.0.x
Other All
: Normal enhancement
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks: 158284
 
 
Reported: 2004-06-16 14:55 UTC by Ray Strode [halfline]
Modified: 2013-12-16 18:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2004-06-16 14:55:23 UTC
Give inappropriate permissions (say 755) to /tmp and gdm will not login, but it
doesn't report a meaningful reason why.  It may be nice to provide an error
explaining the problem. 

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111050 for details.
Comment 1 Brian Cameron 2006-01-12 23:54:55 UTC
I'd accept a patch
Comment 2 Sebastien Bacher 2006-03-16 21:30:24 UTC
Ubuntu bug about a similar issue if tmp has no free space: https://launchpad.net/products/gdm/+bug/35217
Comment 3 Mantas Kriaučiūnas 2006-09-05 16:54:37 UTC
Free space issue is very important for lots of users - they often are installing lots of software or simply downloading lots of stuff and after rebooting they can't login :(
Comment 4 Brian Cameron 2006-09-05 18:41:18 UTC
I agree this would be a great bug to fix.  As I said, I'd happily accept a patch
Comment 5 Mantas Kriaučiūnas 2006-09-08 12:15:40 UTC
(In reply to comment #4)
> I agree this would be a great bug to fix.  As I said, I'd happily accept a
> patch

OK, so let's talk about best way how to solve this bug. For most users problem is, that gdm doesn't work when there are no free space on /tmp and doesn't offer a usable solution for regular user how to free some space in volume.

I've found a good solution for this gdm problem in gnome bug #339229 - gdm should create place-holder file of needed size (for example ~50 kb) in /tmp after gdm starts (also display a warning message if there are no enough space for creating such file) and erase this file in /tmp before gdm starts.

What you think about this way ?
Comment 6 Brian Cameron 2006-09-08 18:45:28 UTC
I'm not sure that I agree that it should be GDM's responsibility to make sure that the user's file system is sane.  GDM is a Display Manager, not the program that ensures that any issue that could confront a user on bootup is addressed.  Are you sure there isn't a more sensible place in the kernel that "protecting the user from filling their file system" should be implemented?  Perhaps systems should be setup with users having quotas by default to avoid the filesystem getting filled?

That said, I do think that GDM should behave nicely in the situation where the
disk is full.  It shouldn't block the user from logging into a failsafe session.  If the user session will hang if the filesystem is full.  It should probably also only allow the user to go into failsafe xterm in this situation and disallow letting the user try to log into other session.  In this case, I don't think any files need to be written on login.

I think a better solution is for GDM to recognize the situation and not start, leaving the user at a console login so they can fix the problem at the console.  It should print out an error message explaining what the user needs to do.

I don't think playing games with the filesystem to ensure that there is free space is a good idea.  Not sure users would really want GDM consuming extra disk space it doesn't really need.

If the filesystem is being filled because some process is writing a lot of stuff, then there is really no guarantee that removing such a placeholder file will free up any space.  It is just as likely that the runaway process will consume the free disk space as soon as it becomes available, and not give GDM or the user time to take advantage of it.  There are all sorts of race conditions here that would be tricky to address, I think.

Though perhaps we can talk this issue through a bit more and come up with a better solution that would resolve the problem.
Comment 7 Vincenzo Ciancia 2006-12-01 22:06:24 UTC
A console login is not an option for many beginners and gnome is definitely targeted also to beginners. Why is free disk space needed to login inside GDM and not in the console?
Comment 8 Brian Cameron 2006-12-01 23:06:38 UTC
A quick look at the GDM code points out that GDM uses /tmp for the following reasons:

+ /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. 

If we wanted GDM to work when /tmp is full, we'd need to make sure that GDM has ways to workaround all the above problems.



Comment 9 vincenzo_ml 2007-01-29 15:20:55 UTC
May I propose the following solution: mount a very small loopback filesystem or even better a ramfs for the sole purpose of hosting all those files? It should be really easy. You mount a small ramfs in /tmp/gdmfs, then you make gdm create all of its files in gdmfs.

Since all these files are temporary and small, this makes sense in my opinion, even if problems arise with .xsession-errors, which is unbound in size. Perhaps .xsession-errors should not exist at all if the user has no free space to write on.


Comment 10 David Liang 2009-03-23 09:18:57 UTC
I meet the problem today, it is really annoying.

(gdm-2.24)
GDM should better show such error message on the error label, just as authentication failed.
Comment 11 Ray Strode [halfline] 2013-12-16 18:03:57 UTC
I'm going to close this out.  I wrote this in 2004, and these days I don't even think it's a good idea.  GDM shouldn't be showing things to the user without a graphical display, imno.