access
ignores setuid/setgid bits. This is by design.
Quoting from man 2 access
on Linux:
The check is done using the calling process's real UID and GID,
rather than the effective IDs as is done when actually attempting an
operation (e.g., open(2)
) on the file. Similarly, for the root user,
the check uses the set of permitted capabilities rather than the set
of effective capabilities; and for non-root users, the check uses an
empty set of capabilities.
This allows set-user-ID programs and capability-endowed programs to
easily determine the invoking user's authority. In other words,
access()
does not answer the "can I read/write/execute this file?"
question. It answers a slightly different question: "(assuming I'm a
setuid binary) can the user who invoked me read/write/execute this
file?", which gives set-user-ID programs the possibility to prevent
malicious users from causing them to read files which users shouldn't
be able to read.
If you want to know whether your process can actually open a file for reading, just open()
it and handle the error, if any. (This also avoids a race condition.)