This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
RE: access call not calling faccessat correctly
The manpage for "access" says it takes 4 arguments.
ACCESS(2) Linux Programmer's Manual ACCESS(2)
NAME
access, faccessat - check user's permissions for a file
SYNOPSIS
#include <unistd.h>
int access(const char *pathname, int mode);
#include <fcntl.h> /* Definition of AT_* constants */
#include <unistd.h>
int faccessat(int dirfd, const char *pathname, int mode, int flags);
-----Original Message-----
From: Florian Weimer <fweimer@redhat.com>
Sent: Monday, October 21, 2019 11:08 AM
To: Michael Morrell <mmorrell@tachyum.com>
Cc: libc-help@sourceware.org
Subject: Re: access call not calling faccessat correctly
* Michael Morrell:
> I was seeing a failure in the chmod_1.f90 test that is part of gcc's validation testsuite and am pretty sure it is caused by some bad code in glibc.
>
> In sysdeps/unix/sysv/linux/access.c, a call to "access()" is implemented by either calling the access syscall or the faccessat syscall, depending on whether __NR_access is #defined. If __NR_access is not #defined and the faccessat syscall is used, it is only called with 3 arguments - no value for the flags argument is passed. This causes EINVAL to be returned in some cases, depending on whatever happens to be in the register that would be used to pass that argument.
>
> I think the change is simple:
>
> diff --git a/sysdeps/unix/sysv/linux/access.c
> b/sysdeps/unix/sysv/linux/access.c
> index 524594ac79..706f242adb 100644
> --- a/sysdeps/unix/sysv/linux/access.c
> +++ b/sysdeps/unix/sysv/linux/access.c
> @@ -26,7 +26,7 @@ __access (const char *file, int type) #ifdef
> __NR_access
> return INLINE_SYSCALL_CALL (access, file, type); #else
> - return INLINE_SYSCALL_CALL (faccessat, AT_FDCWD, file, type);
> + return INLINE_SYSCALL_CALL (faccessat, AT_FDCWD, file, type, 0);
> #endif
> }
> weak_alias (__access, access)
>
> I haven't filed a bug yet, but can do so.
The faccessat system call takes only three arguments. It's always been this way.
What you are seeing must be the result of something else.
Thanks,
Florian