在Java中，File.canExecute（）究竟做了什么？

I have created a plain file which does not have execute permission but when I create a Java File object using this file's path/name and then call File.canExecute() I get true as the result, whereas I would expect this method call to return false. Can someone explain what I'm missing here?

我创建了一个没有执行权限的普通文件,但是当我使用这个文件的路径/名称创建一个Java File对象然后调用File.canExecute()时,我得到了结果,而我希望这个方法调用返回假。谁能解释我在这里缺少的东西?

Solaris:

$ touch /tmp/nonexecutable
$ ls -l /tmp/nonexecutable
-rw-r--r--   1 root     root           0 May 21 07:48 /tmp/nonexecutable

Java:

String pathName = "/tmp/nonexecutable";
File myFile = new File(pathName);
if (!myFile.canExecute())
{
    String errorMessage = "The file is not executable.";
    log.error(errorMessage);
    throw new RuntimeException(errorMessage);
}

Thanks in advance for your help.

在此先感谢您的帮助。

--James

3 个解决方案

#1

Nothing to do with Java - you're running as root, and root is allowed everything, not matter what the permissions say.

与Java无关 - 你以root身份运行,root允许一切,无论权限说什么。

#2

Though I'm not an expert, and this will not answer your question properly, I'd like to add that this behavior is not specific to Java. From the find (GNU findutils) 4.4.0 manpage on my Ubuntu 8.10 install, regarding the -executable flag:

虽然我不是专家,但这不能正确回答您的问题,但我想补充一点,这种行为并非特定于Java。在我的Ubuntu 8.10安装的find(GNU findutils)4.4.0手册页中,关于-executable标志:

Matches files which are executable and directories which are searchable (in a file name resolution sense). This takes into account access control lists and other permissions artefacts which the -perm test ignores. This test makes use of the access(2) system call, and so can be fooled by NFS servers which do UID mapping (or root-squashing), since many systems implement access(2) in the client’s kernel and so cannot make use of the UID mapping information held on the server. Because this test is based only on the result of the access(2) system call, there is no guarantee that a file for which this test succeeds can actually be executed.

匹配可执行文件和可搜索的目录(在文件名解析意义上)。这会考虑访问控制列表和-perm测试忽略的其他权限假象。此测试使用access(2)系统调用,因此可以被执行UID映射(或root-squashing)的NFS服务器所欺骗,因为许多系统在客户端内核中实现access(2),因此无法使用服务器上保存的UID映射信息。由于此测试仅基于access(2)系统调用的结果,因此无法保证可以实际执行此测试成功的文件。

#3

Here is a bug which was opened on JDK on this:

这是在JDK上打开的一个错误:

http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=8b833c54cb93d6c9cf416667dc02?bug_id=6379654

The conclusion is that File.canExecute() simply translates into a native posix call to access(path, X_OK). Linux returns false and solaris returns true for that call when run as root.

结论是File.canExecute()只是转换为访问的本机posix调用(path,X_OK)。当以root身份运行时,Linux返回false并且solaris为该调用返回true。

Finally, the bug was closed as Wont Fix! :)

最后,该bug被关闭为Wont Fix! :)

#1