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. [EMAIL PROTECTED] | -- Philip K. Dick http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature