You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stian Soiland-Reyes (JIRA)" <ji...@apache.org> on 2016/05/05 09:23:12 UTC

[jira] [Created] (VFS-604) PermissionsTests fail if built on noexec mounted file system (e.g. tmpfs)

Stian Soiland-Reyes created VFS-604:
---------------------------------------

             Summary: PermissionsTests fail if built on noexec mounted file system (e.g. tmpfs)
                 Key: VFS-604
                 URL: https://issues.apache.org/jira/browse/VFS-604
             Project: Commons VFS
          Issue Type: Bug
    Affects Versions: 2.1
         Environment: Ubuntu 14.04, with noexec mounted tmpfs

{code}
stain@biggie:/tmp/vfs$ cat /etc/fstab| grep tmp
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=4G 0 0
{code}

and OpenJDK 8

{code}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_72-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-67-generic", arch: "amd64", family: "unix"
{code}
            Reporter: Stian Soiland-Reyes
            Priority: Trivial


If Commons VFS is compiled on a file system mounted with the noexec flag, e.g.  on /tmp with tmpfs, then the PermissionsTests.testExecutable fails:

{code}
Tests run: 90, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.259
sec <<< FAILURE! - in
org.apache.commons.vfs2.provider.local.test.LocalProviderTestCase
testExecutable(org.apache.commons.vfs2.test.PermissionsTests)  Time
elapsed: 0.011 sec  <<< FAILURE!
java.lang.AssertionError
    at org.junit.Assert.fail(Assert.java:86)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertTrue(Assert.java:52)
    at org.apache.commons.vfs2.test.PermissionsTests.testExecutable(PermissionsTests.java:70)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
    at junit.framework.TestCase.runBare(TestCase.java:141)
    at junit.framework.TestResult$1.protect(TestResult.java:122)
    at junit.framework.TestResult.runProtected(TestResult.java:142)
    at junit.framework.TestResult.run(TestResult.java:125)
    at junit.framework.TestCase.run(TestCase.java:129)
    at junit.framework.TestSuite.runTest(TestSuite.java:252)
    at junit.framework.TestSuite.run(TestSuite.java:247)
    at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
    at org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
    at junit.framework.TestResult.runProtected(TestResult.java:142)
    at org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
{code}

See http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAMBJEmVkgqCbnz4BUJ7KpBn_cyTgxgJJiy%3D16dJQxNcyTT_c4w%40mail.gmail.com%3E

I must admit this is a bit weird - because you ARE allowed to set exec permissions - they just don't work when trying to run.

{code}
stain@biggie:/var/tmp$ echo '#!/bin/cat' > hello
stain@biggie:/var/tmp$ chmod 755 hello 
stain@biggie:/var/tmp$ ./hello 
#!/bin/cat

stain@biggie:/var/tmp$ cd /tmp
stain@biggie:/tmp$ echo '#!/bin/cat' > hello
stain@biggie:/tmp$ chmod 755 hello 

stain@biggie:/tmp$ ./hello 
-bash: ./hello: Permission denied

stain@biggie:/tmp$ ls -al hello 
-rwxr-xr-x 1 stain stain 11 May  5 10:16 hello
{code}

So I don't think Commons VFS is doing something wrong - file.isExecutable() is still false even though setExecutable() (presumably) succeeds - but the test could be improved to check the return values. Unless the signature for isExecutable should read what the file permission is SET as (e.g. replicate ls -al), rather than what the EFFECTIVE permission is (can I execute it?).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)