Re: [BUG] Generic syscalls -- chmod vs. fchmodat

From: Eric Blake
Date: Tue Jan 25 2011 - 15:32:00 EST

On 01/25/2011 12:56 PM, Eric Blake wrote:
>>> Treating the empty string special for AT_FDCWD is rather pointless, but
>>> at least consistent.
> No, treating an empty string name argument to a *at function as a
> synonym for AT_FDCWD is a violation of POSIX.
>> i dont know if the gnulib peeps are on these lists, but i think their
>> implementations of some of the *at funcs leverage the extended behavior that
>> is available under Linux. or at least, i'm certain they'll have some insight
>> into some of these nuances.
> Gnulib has code to explicitly work around bugs in earlier glibc/Linux
> implementations that mistakenly treated fd, "" the same as fd, "." (at
> least modern kernels get it right, and when glibc defers to the kernel,
> those workarounds in gnulib are not needed on newer systems).

One other thing to point out - this is not the first time glibc has
added code around *at kernel syscalls in order to provide POSIX
semantics where the Linux syscall does not. Remember that both futimens
and utimensat are implemented on top of the same syscall, and that
futimens(AT_FDCWD, times) must fail rather than set the times on ".".
See glibc commit 4286fa41 where glibc had to add code to work around the
kernel's choice of the syscall utimensat(fd, NULL, times, 0) as being
the way to implement futimens, in response to, which was raised
because gnulib detected the POSIX compliance bug, in much the same way
that gnulib is now detecting the chmod("") bug of not failing with
ENOENT when chmod is incorrectly implemented around the sys_fchmodat

Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature