为什么 Linux 不执行具有 Java 执行权限的 bash 脚本？

Question

There are numerous questions that look similar to this, but none of them seem to be exactly the same and all their solutions have not worked for me, so here it goes...

I have a Java program that tries to auto-update itself. It works like this:

• on startup, a bash script checks for the presence of a zip file in a certain location.
• if it exists, instead of running the "real" main class, it runs the updater Java class.
• this class will unpack the zip in a temp location, then start itself again in a separate process, from that temp location.
• once the new process starts, the old one exits.
• the new process tries to unpack the zip again, into the previous location (which now has nothing running so can be replaced).
• on success, it deletes the zip file and runs the original bash script again.

If everything worked, the bash script now would just start the Java main class.

Everything in this list actually works, except for the very last step when I try to execute the bash script at the end.

The bash file permissions look like this (both before and after I run the auto-updater):

-rwxr-xr-x

As far as I can see, there should be no permissions issue running this file (and in fact, I can run it manually immediately after the process crashes).

Here's the error I get:

java.io.IOException: Cannot run program "/home/xxx/build/image/bin/run": error=13, Permission denied
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.Runtime.exec(Unknown Source)
at java.base/java.lang.Runtime.exec(Unknown Source)
at java.base/java.lang.Runtime.exec(Unknown Source)
at my_mod/my.Main.main(Unknown Source)

I wrote a "process bomb" that works similarly, but that worked:

• start by running a bash script that launches a main class

• the main class uses the following code to start the bash script again:

   // DO NOT RUN THIS AT HOME, // IT WILL START LOTS OF PROCESSES INFINITELY // if you do want to try it. have "killall -9 java" ready. try { Runtime.getRuntime();exec( path ) System.exit(0); } catch ( Exception e ) { e.printStackTrace(); }

So I think that this is not some kind of Linux protection against process bombs like this.

But I am completely puzzled why Linux is still denying access to running that bash script after the update.

My OS is Ubuntu 19.

How can I find out why it's denying access, and more importantly, how can I fix it?

Answer 1

I have finally found out the root cause of the problem: it was due to file permissions, but not with the file the error message mentions !

The way I was unpacking the new application update was via writing a simple "unzipper" in Java with the following, basic implementation:

    try (var zip = new ZipInputStream(
            new BufferedInputStream(
                    new FileInputStream(newVersionZipFile), 4096))) {
        var zipEntry = zip.getNextEntry();
        if (zipEntry == null) {
            throw new IllegalStateException("Expected at least one entry in the zip file: " + newVersionZipFile);
        }
        var topEntryName = zipEntry.getName();
        zipEntry = zip.getNextEntry();
        while (zipEntry != null) {
            var file = fileFor(zipEntry, destinationDir, topEntryName);
            if (isDirectory(zipEntry)) {
                var ok = file.mkdir();
                if (!ok) throw new IllegalStateException("Cannot create new directory: " + file);
            } else {
                Files.copy(zip, file.toPath());
            }
            zipEntry = zip.getNextEntry();
        }
    }

This actually works, mostly, but it has a big problem: it does not consider file permissions. I had noticed the problem and made everything in the bin directory executable after unzipping, but what I had not anticipated was that there more executable files in the minimal-JVM created by jlink. And because the application actually mostly worked, that made me think everything was fine!

Using the tree command, I looked at the directory tree after unzipping it with Linux's unzip , and with my custom Java unzip. I noticed that, with unzip , besides the files in the bin directory, the following files also had execution permission:

├── [drwxrwxr-x]  lib
│   ├── [-rw-rw-r--]  classlist
│   ├── [-rw-rw-r--]  javafx.properties
│   ├── [-rw-rw-r--]  javafx-swt.jar
│   ├── [-rwxrwxr-x]  jexec
│   ├── [-rw-rw-r--]  jrt-fs.jar
│   ├── [-rwxrwxr-x]  jspawnhelper
...

In contrast, the tree unzipped by the Java unzipper looked like this:

├── [drwxrwxr-x]  lib
│   ├── [-rw-rw-r--]  classlist
│   ├── [-rw-rw-r--]  javafx.properties
│   ├── [-rw-rw-r--]  javafx-swt.jar
│   ├── [-rw-rw-r--]  jexec
│   ├── [-rw-rw-r--]  jrt-fs.jar
│   ├── [-rw-rw-r--]  jspawnhelper
...

Noticed that two files are supposed to have execution permission: jexec and jspawnhelper , both of which have names that strongly suggest they have something to do with executing other processes:D

To test this hypothesis, I made the unzipper also change the permissions of these two files to executable, and now everything works as expected!

My challenge now turns to how to actually keep the file permissions of all files when unzipping it, and that's another rabbit hole as there is no standard way to get file permissions from a standard zip (which is why the Java API for zips does not have that feature). There are external libraries that mostly work, so I'll probably end up using one of them... but that's another topic.