On Tue, 23 May 2006, Jason Riedy wrote:
>
> - Btw, even SuS says:
> [...]
> - New implementations are discouraged from returning X_OK unless at
> - least one execution permission bit is set."
>
> Now there is one possible, cross-OS problem that I
> haven't tested. You can chmod a-x and then use
> setfacl to grant one person execute access. I'm not
> sure if access works in that case, but that might
> possibly just say that current ACL systems are crap.
I absolutely agree. That is why the OS has a "access()" system call. It's
there to ask the OS whether the file is executable (or readable/writable).
Otherwise, we'd just do
static inline int executable(const char *path)
{
struct stat st;
return !stat(pathname, &st) &&
S_ISREG(st.st_mode) &&
(st.st_mode & 0111) != 0;
}
and be done with it. But exactly because the OS knows what "executable"
means, we ask it. We don't know about all the ACL's etc, the OS does.
(Similar issues are true for writability too - the file may be "writable"
in the sense that the write permission bits are on, but if the filesystem
is mounted read-only, it sure as hell ain't W_OK _anyway_).
> Hmm. Does access handle SELinux or the other systems?
Yup.
Modulo bugs, of course, but yes, access() on linux should check both
POSIX ACL's and SELinux security extensions. It uses exactly the same
code-paths that open()/execve() does: it uses the "vfs_permission()"
function which is also what execve() uses.
Now, I think access() actually misses a no-exec mount (it doesn't seem to
check MNT_NOEXEC for X_OK), and that looks like it might actually be a
real bug.
Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html