SPECS: sudo.spec - workaround for broken utimes on sparc. see at: ...

[Jakub Bogusz]

On Sat, Jun 11, 2005 at 11:50:46PM +0200, The Undefined wrote:
> On Sat, Jun 11, 2005 at 10:28:09AM +0200, Jakub Bogusz wrote:
> > > Author: undefine                     Date: Wed Jun  8 23:04:08 2005 GMT
> > > Module: SPECS                         Tag: HEAD
> > > ---- Log message:
> > > - workaround for broken utimes on sparc. see at: http://tinyurl.com/ckh4f
> > 
> > Z którą wersją glibc był problem?
> chyba jest...
> [guest w ares guest]$ sudo echo   
> Password:
> 
> [guest w ares guest]$ sudo echo 
> sudo: timestamp too far in the future: Jul 27 14:25:28 2029
> 
> We trust you have received the usual lecture from the local System
> Administrator. It usually boils down to these three things:
> 
>     #1) Respect the privacy of others.
>     #2) Think before you type.
>     #3) With great power comes great responsibility.
> 
> Password:
> (przed chwilką specjalnie zdowngradowałem sudo by się upewnić że problem
> wciąż występuje).
> 
> [guest w ares guest]$ rpm -q sudo glibc; uname -a
> sudo-1.6.8p8-2
> glibc-2.3.5-1
> Linux ares 2.4.20 #4 wto gru 3 09:29:27 CET 2002 sparc64
> TI_UltraSparc_IIi unknown PLD Linux
> 
> generalnie - całość jest niedeterministyczna. czasami działa, czasami
> nie...
> na sudo z "workaroundem" wszystko działa ok...

A możesz uruchomić (ew. kilka razy) na tej maszynie testowy program?
Dla przypomnienia:

$ cat utimes.c
#include <sys/types.h>
#include <utime.h>
#include <sys/time.h>

int main()
{
        struct timeval tvp[2];
        tvp[0].tv_sec = 1000000000;
        tvp[0].tv_usec = 444444;
        tvp[1].tv_sec = 1111111111;
        tvp[1].tv_usec = 555555;
        utimes("utimes", tvp);
}
$ cc -o utimes utimes.c
$ ./utimes
$ stat utimes

Sprawdziłem to jeszcze na 2.4.30/sparc64 z glibc 2.3.4-0.20041122.2 - też
działa poprawnie. sudo chwilowo nie mogę sprawdzić.

Albo z 2.4.20 coś było nie tak z utimes, albo błąd jest gdzie indziej
(np. w pochodzeniu wartości przekazywanych do utimes).
Te nieprawidłowe daty (2029-*) mają wartość 0x700xxxxx - wyglądają jak
adresy zinterpretowane jako time_t.

Albo - ale nie wiem, czy to może się ujawnić przy 32-bitowym userspace -
jest to wynik paskudnego błędu naprawionego dopiero w 2.4.21:
http://linux.bkbits.net:8080/linux-2.4/diffs/arch/sparc64/kernel/signal.c@1.10?nav=index.html|src/.|src/arch|src/arch/sparc64|src/arch/sparc64/kernel|hist/arch/sparc64/kernel/signal.c


-- 
Jakub Bogusz    http://qboosh.cs.net.pl/