In Java, what exactly does File.canExecute () do?

Question

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

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

Answer 1

Nothing to do with Java - you work as root, and everything is allowed as root, no matter what permissions say.

Answer 2

Although I am not an expert, and this will not answer your question correctly, I would like to add that this behavior is not specific to Java. On the findtils find (GNU findutils) 4.4.0 page in my Ubuntu 8.10 installation regarding the -executable flag:

Corresponds to files that are executable files and directories that are to be searched (in the name resolution of the file makes sense). This takes into account access control lists and other artifact permissions that the -perm test is ignored. This test uses the access(2) system call, and therefore they can be fooled by NFS servers that do UID mapping (or root-squashing), since many systems implement access(2) in kernel clients and therefore cannot use the UID mapping information stored on server. Since this test is based solely on the result of the access(2) system call, there is no guarantee that the file for which this successful test is performed .

Answer 3

Here is the error discovered in the JDK:

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

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

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