__atfct_seterrno() or futimesat() broken

__atfct_seterrno() or futimesat() broken

[Thorsten Kukuk]

Hi,

if you call futimesat() without kernel syscall support and without
/proc mounted you will get a seg.fault in __atfct_seterrno():

(gdb) down
#0  0x400d8f53 in __atfct_seterrno (errval=2, fd=0,
    buf=0xbfffe4e0 "/proc/self/fd/0") at openat.c:61
61                *(char *) strchr (buf + sizeof "/proc/self/fd", '/') = '\0';


The problem is that all *at.c files uses:
static const char procfd[] = "/proc/self/fd/%d/%s";

except futimesat.c, which does not append the filename after the
file descriptor (as you can see from gdb output).
So the strchr will not find a "/" and the return value is NULL.

First question is: Should futimesat.c append the filename, too, or
should it not call __atfct_seterrno?

Second question about __atfct_seterrno: This function only checks for
ENOTDIR if /proc is mounted. Why? utime() in futimesat.c returns
ENOENT for this case:

utimes("/proc/self/fd/0", NULL)         = -1 ENOENT (No such file or directory)

Shouldn't the check, if /proc is mounted, be the first on in 
__atfct_seterrno?

  Thorsten

-- 
Thorsten Kukuk         http://www.suse.de/~kukuk/      kukuk@suse.de
SUSE LINUX Products GmbH       Maxfeldstr. 5       D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: __atfct_seterrno() or futimesat() broken

[Roland McGrath]

I don't see how the lstat check that did the problematic string twiddling
was actually doing anything for us not better done by the fstat check for
the EBADF case.  I changed it to use the simple fstat check for EBADF on
ENOENT as well as ENOTDIR, which gets rid of the code with the bad
assumptions about the contents of BUF.  I also made it do the check for
missing /proc on ENOENT as well.  There are in fact many other potential
error codes that could be /proc is not mounted as expected, but ENOENT is
in fact the most likely one (and ENOTDIR possible, but not perhaps any more
likely than several others).


Thanks,
Roland