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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D3F2AD9.8060000@redhat.com>
Date:	Tue, 25 Jan 2011 12:56:09 -0700
From:	Eric Blake <eblake@...hat.com>
To:	Mike Frysinger <vapier@...too.org>
CC:	Arnd Bergmann <arnd@...db.de>, Paul Eggert <eggert@...ucla.edu>,
	Roland McGrath <roland@...hat.com>, linasvepstas@...il.com,
	Chris Metcalf <cmetcalf@...era.com>,
	GLIBC Devel <libc-alpha@...rceware.org>,
	linux-kernel@...r.kernel.org, libc-ports@...rceware.org,
	linux-api@...r.kernel.org
Subject: Re: [BUG] Generic syscalls -- chmod vs. fchmodat

On 01/25/2011 11:52 AM, Mike Frysinger wrote:
> On Tuesday, January 25, 2011 13:21:14 Arnd Bergmann wrote:
>> On Tuesday 25 January 2011 18:45:15 Roland McGrath wrote:
>>>  I know of no reason to
>>>
>>> think that the current treatment of the empty string was ever intended at
>>> the creation of the *at interfaces.
>>
>> I always assumed that this was done so that the *at syscalls can replace
>> both the ones that take a file descriptor (e.g. fstat) and the ones that
>> take a pathname (e.g. stat), which is sensible for the non-AT_FDCWD case,
>> although not documented in the man pages.

For futimesat, which is not specified by POSIX, gnulib already requires
the behavior of calling futimesat(fd, NULL, times) as a way to directly
modify the (possibly non-directory) fd, in contrast to futimesat(fd,
"name", times), which sets the times on "name" relative to the directory fd.

For all other *at interfaces, they are specified by POSIX as requiring
the same behavior as the non-*at interface when given arguments within
the bounds required by POSIX.  That is, fstatat(fd, "", buf, 0) SHALL
fail with ENOENT, just the same as stat("", buf).  However, since POSIX
requires that the second argument be a valid string, and NULL is not a
valid string, then passing NULL as the second argument means that you
are no longer bound by POSIX and that you could (if you wanted) make
fstatat(fd, NULL, buf, 0) behave the same as fstat(fd, buf).  Right now,
none of the other *at interfaces in Linux currently do this; futimesat
is the only interface explicitly documented as having this dual behavior.

>>
>> 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).

-- 
Eric Blake   eblake@...hat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Download attachment "signature.asc" of type "application/pgp-signature" (620 bytes)