How to assign execute permission to a .sh file in windows to be executed in linux

Question

Here is my problem,

In Windows I am making a zip file in which there is a text .sh file which is supposed to be executed in Linux. The user on the other end opens the zip file in Linux and tries to execute the .sh file but the execute permission is gone. So the user has to do it manually ( like explained here:add execute permission.

How can I in Windows make the .sh executable and add it to a zip file so that when the zip file opens in linux the .sh file still retains its execute permission ( so that user doesn't have to do it manually)

Solution 1

As far as I know the permission system in Linux is set up in such a way to prevent exactly what you are trying to accomplish.

I think the best you can do is to give your Linux user a custom unzip one-liner to run on the prompt:

unzip zip_name.zip && chmod +x script_name.sh

If there are multiple scripts that you need to give execute permission to, write a grant_perms.sh as follows:

#!/bin/bash
# file: grant_perms.sh

chmod +x script_1.sh
chmod +x script_2.sh
...
chmod +x script_n.sh

(You can put the scripts all on one line for chmod, but I found separate lines easier to work with in vim and with shell script commands.)

And now your unzip one-liner becomes:

unzip zip_name.zip && source grant_perms.sh

Note that since you are using source to run grant_perms.sh, it doesn't need execute permission

Solution 2

The ZIP file format does allow to store the permission bits, but Windows programs normally ignore it. The zip utility on Cygwin however does preserve the x bit, just like it does on Linux. If you do not want to use Cygwin, you can take a source code and tweak it so that all *.sh files get the executable bit set. Or write a script like explained here

Solution 3

This is possible using the Info-Zip open-source Zip utilities. If unzip is run with the -X parameter, it will attempt to preserve the original permissions. If the source filesystem was NTFS and the destination is a Unix one, it will attempt to translate from one to the other. I do not have a Windows system available right now to test the translation, so you will have to experiment with which group needs to be awarded execute permissions. It'll be something like "Users" or "Any user"

Solution 4

Use my windows command line utility zip_exec.zip to set the executable flag for linux/unix and mac (tested on files created with Windows Explorer and 7zip). The cpp source is also available. I searched the internet a lot before making my own utility. It can be modified to set any file attribute.

View more solutions

Comments

[itsbruce]

It is possible and you are quite wrong about the permissions. Any of the various archival/unarchival tools available for Unix (tar, gzip, bzip2) will preserve both ownership and permissions and will restore permissions (with the right parameters) for any user, and will restore the original group/owner id if run by root (with the appropriate parameters).

[itsbruce]

This is quite wrong; nothing about the permission system is set up to defeat this. How did you reach this conclusion?

[sampson-chen]

@itsbruce I look forward to seeing your answer to this question then; I was taught that Linux was built on the fail-safe default / least privilege model: I would be learning something new if what you are suggesting is possible.

[itsbruce]

I don't think you understand how file permissions work. As I have said elsewhere, all the native Unix archival tools preserve file permissions and will restore them with the correct parameters. Take a look at the man page for GNU tar; specifically, the -p (or --same-permissions or --preserve-permissions option.

[itsbruce]

How do you think it is a security hole, by the way? It would be a security hole if non-root users could preserve ownership; it is not a security hole if permissions are set but ownership is restricted to that of the unarchiving user.

[dmarra]

I think you meant to reply to my answer itsbruce. You've stated your case well though. TIL.

[Gianluca Ghettini]

archiving is just a mean, what's the difference between archiving a file and leave the same file on the filesystem from the permissions perspective? no security hole is created during the archiving process...

[C graphics]

@itsbruce So what is the right answer though?How is it possible to do what I asked to do in my question?

[itsbruce]

I have given you almost the entire answer in my answer. I have told you which tool can do it; you just have to experiment with the right NTFS group permissions (get a Linux user to help if you don't run Linux anywhere). Or ask the InfoZip maintainers or user mailing list.

[sampson-chen]

If you end up testing this for Windows-to-Linux sometime, I would actually like to know if there's any difficulty with applying the method described (and if so, any work-arounds)

[stefan.seeland]

I proved the behavior of tar/bz2 in Cygwin on NTFS and was surprised that the execution bit was not taken from the value that is shown when "ls -la" is executed. Instead there is some list of file extension that is triggering the execution bit to be set. In case of sh, exe and dll the execution bit is set. On others that are not on this list the execution bit is removed. It seems that cygwin.com/cygwin-ug-net/using-filemodes.html is not the complete truth, because the doc claims that the value gets calced form some NTFS thing. That is not true in case of the execution bit.

[stefan.seeland]

After reading unix.stackexchange.com/questions/549908/… I am not sure that my first comment is correct. I possibly ran into some Cygwin/MiniGW side effect issue and Cygwin would do fine without MiniGW on the same machine.