[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#253480: xdm: XDM fails if the user is over disk quota, but empty files can be created

tag 253480 + moreinfo

On Wed, Jun 09, 2004 at 01:52:03PM -0400, Arcady Genkin wrote:
> Package: xdm
> Version: 4.2.1-15.backports.org.1
> Severity: important
> Note: I am using the 4.2.1-15 package from backports.org, but this bug
> also exists in all XDM versions.

I find it difficult to believe that you've reproduced in "all XDM
versions"; please do not overstate your case when filing a bug report.

Also, the Debian Project doesn't support unofficial versions like the
one you reported this bug against.

Nevertheless, I'll see what I can do about it; I can see how the
behavior you describe would be aggravating.

> This is really a bug upstream (i.e.  not a Debian-specific bug), but,
> perhaps, can be fixed rather easily.


> The XDM's fallback mechanism for creating the .Xauthority file does not
> work in the situations when the user is over disk quota in his home
> directory, but empty files can be created.
> Acording to the XDM's man page:
>        DisplayManager.DISPLAY.userAuthDir
>               When  xdm  is  unable  to  write  to the usual user
>               authorization file ($HOME/.Xauthority), it  creates
>               a unique file name in this directory and points the
>               environment variable XAUTHORITY at  the created file.
> 	      It uses /tmp by default.  
> This information is incorrect, since XDM does not check whether it can
> *write* to the file, only that it can open() it.

Actually, you're mistaken.  However, by the time it tests writing, it
may be too late...

The code that does this is in a function called SaveServerAuthorizations
in xc/programs/xdm/auth.c:

    352 int
    353 SaveServerAuthorizations (
    354     struct display  *d,
    355     Xauth           **auths,
    356     int             count)
    357 {
    358     FILE        *auth_file;
    359     int         mask;
    360     int         ret;
    361     int         i;
    362     int         fd;
    364     mask = umask (0077);
    365     if (!d->authFile && !MakeServerAuthFile (d))
    366         return FALSE;
    367     (void) unlink (d->authFile);
    368     fd = open (d->authFile, O_WRONLY | O_CREAT | O_EXCL, 0600);
    369     if (fd >= 0)
    370         auth_file = fdopen (fd, "w");
    371     else
    372     {
    373         LogError ("cannot create server authorization file %s: %s\n",
    374                   d->authFile, _SysErrorMsg (errno));
    375         Debug ("can't create auth file %s\n", d->authFile);
    376     }
    377     (void) umask (mask);
    378     if (!auth_file)
    379     {
    380         free (d->authFile);
    381         d->authFile = NULL;
    382         ret = FALSE;
    383     }
    384     else
    385     {
    386         Debug ("file: %s auth: %p\n", d->authFile, auths);
    387         ret = TRUE;
    388         for (i = 0; i < count; i++)
    389         {
    390             /*
    391              * User-based auths may not have data until a user logs in, in
    392              * which case don't write to the auth file so xrdb and setup
    393              * programs don't fail.
    394              */
    395             if (auths[i]->data_length > 0)
    396                 if (!XauWriteAuth (auth_file, auths[i]) ||
    397                     fflush (auth_file) == EOF)
    398                 {
    399                     LogError ("cannot write to server authorization file %s\n",
    400                               d->authFile);
    401                     ret = FALSE;
    402                     free (d->authFile);
    403                     d->authFile = NULL;
    404                 }
    405         }
    406         fclose (auth_file);
    407     }
    408     return ret;
    409 }

> Because of this, if the user is over disk quota in such a way that he
> can't write to the files, but can create empty files, this fallback
> mechanism does not work; XDM then fails to create the .Xauthority file
> and the XDM session is terminated.
> This is very aggravating for the users who can only log in at the
> graphical console, because they are left without any means of cleaning
> up their disk space.
> At the very least, the man page should be modified to read "When xdm is
> unable to *create* the usual user authorization file...".

You may interested to know that Debian has modified auth.c (our modified
version as currently used in unstable appears above) to create the
authFile more securely.  At the time I wrote it, I had another Debian
developer, Richard Braakman, have a look at it.  Here's what he said:

    - Richard Braakman observes the following about the above changes: "I
      can think of only one case where the new behaviour could be a
      problem: if a user already has a file ".Xauthority-n" in $HOME and
      the user's home directory is not writable for self (so the unlink
      fails) and the .Xauthority-n file _is_ writable then the old fopen
      would have succeeded (and truncated the file), while the new code
      would fail.  Well, tough titties."  Since "-n" files are cleaned
      shortly after they are created, the existence of any such file would
      be an anomaly (the result of an xdm or xinit process getting killed
      at an inopportune moment).  This doesn't seem like an important

I take it that one way to interpret this bug report is that you disagree
with the above.  :)

G. Branden Robinson                |     Reality is what refuses to go away
Debian GNU/Linux                   |     when I stop believing in it.
branden@debian.org                 |     -- Philip K. Dick
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature

Reply to: