tag 253480 + moreinfo
thanks
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.
Perhaps.
> 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;
363
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
concession.
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