script permissions

[worker201]

When I write a shell script in vi or gedit, and then attempt to execute it, permission is denied. I have to change the permissions before I can use it. This seems to be default behavior, and I understand the security reasons for it, but it's kinda annoying. Is there anyway I can change this behavior safely?

[ZiaTioN]

Safely? Probably not simply becasue making a script executable by all (0777) by default is not wise but it is more then possible. Simply manipulate the umask setting for default system wide file permissions. Most default systems have 0022 as the umask setting.

Meaning:

0777 = default executable file permissions
0666 = default text file permissions.

Take these values and subtract the umask value.

0777 - 0022 = 0755 = executable file permissions.
0666 - 0022 = 0644 = text file permissions.

[Void Main]

This is normal behavior and you do not want to set your umask so that everything is executable. You don't actually have to set the executable bit on a script to run it though. You can preface the script name with the interpereter you want to run it with. For instance, if it is a perl script you could:

$ perl myscript.pl

rather than

$ mysqlcript.pl

The first example does not require that the script have the executable bit set. The reason for this is because in UNIX and Linux an executable program can have any name. A file is known to be executable by whether it's executable bit is set. In DOS/Windows it uses file extensions to determine if a file is executable or not. I much prefer the *NIX way. Of course not all files you create should be executable and I certainly wouldn't want them to be set that way by default. It's not hard to do this:

$ chmod +x myscript

P.S. In Red Hat/Fedora the default umask is 0002 for normal users and 0022 for root.

[worker201]

Okay. I use a lot of shell scripts in my work. GMT and MBSystem (mapping packages) are actually collections of dozens of programs, and most of the variables are passed to numerous mini-programs when producing a map. Additionally, it is necessary to make continual minor changes to the scripts. It makes great sense to automate this process with bash scripting.

So, before I asked this question, I was setting my scripts to 777. I would like to back out of this to what they should have been, and then set them executable properly. Any idea what they should have been originally?

[Void Main]

I never, ever, set anything 777 (at least that I can think of). It's impossilble for me to answer your question without knowing more about your environment. There is more than just mode (755,640, etc) involved with permissions. There is also owner and group, and other things actually but those are the basics. I am always careful to set my permissions properly no matter whether it's a system that only I use or if it is a system that 50,000 people use. You set the permissions up according to who needs to be able to do what to the files and directories you are dealing with.

Regardless of the ownership if you set a file 777 then not only can anyone read and execute it but they can also write to it. Now you may not be concerned about the people using your system but obviously they can plant whatever they want in the file with those permissions. Probably *more* of a problem than that happening is that they can "accidentally" change the file or wipe it out (another reason I set permissions properly on machines that only I use). If file security is set up with this amount of insecurity I can't help but think the security of the entire machine is in doubt and someone with less than good intentions might find an easy way in, and be able to easily plant whatever they want in the insecure files.

For me though it's just a way of keeping the honest people honest a lot of times, and it's just plain good practice. This doesn't relate specifically to your example but I absolutely cringe when I see people tell other people who are setting up a web site to set the permissions on all the files to 777 and owned by the web server user apache (or nobody, depending on what user the web server process runs under). Either one of those suggestions (the mode or the owner) by themselves is absolutely the worst advice you can get and will ensure that your site ends up here very soon:

http://www.zone-h.com/en/defacements/special

[caveman]

Just a little info.

My files by default are created with a mode of 644.

Now something to think about - and maybe give a a different idea
in how to use scripts is the so-called "dot" command eg.
a file called xxx.sh with a mode of 644 can be executed by using
". ./xxx.sh" - that is
a dot followed by a space followed by the script name or
fully qualified path name.

BUT beware.... that a script executed with a dot command acts
on the current environment ie. environment variables set in the
script are available to the shell after the script is done, which
is not the case running a script in the normal manner.

This enables one to make changes to the .profile script and execute
it with ". ./.bash_profile" to setup the current shell without
having to log-off and on to test it.

<edit>
hmm - fixed the typo of using "mask" instead of "mode" above...
</edit>

[Void Main]

Caveman, your files are created with a "mode" of 644, not a "mask". Mask and mode are related but not the same thing. Use the "umask" command to change the mask or to view the current mask.

Code: Select all

[voidmain@laplinux ~]$ umask
0002
[voidmain@laplinux ~]$ touch test
[voidmain@laplinux ~]$ ls -l test
-rw-rw-r--  1 voidmain voidmain 0 Feb 27 14:22 test
[voidmain@laplinux ~]$ umask 0022
[voidmain@laplinux ~]$ touch test2
[voidmain@laplinux ~]$ ls -l test2
-rw-r--r--  1 voidmain voidmain 0 Feb 27 14:23 test2
[voidmain@laplinux ~]$ umask 0000
[voidmain@laplinux ~]$ touch test3
[voidmain@laplinux ~]$ ls -l test3
-rw-rw-rw-  1 voidmain voidmain 0 Feb 27 14:23 test3


If your mask really was set to 644 this is what you would get when you create files:

Code: Select all

[voidmain@laplinux ~]$ umask 644
[voidmain@laplinux ~]$ touch test4
[voidmain@laplinux ~]$ ls -l test4
-----w--w-  1 voidmain voidmain 0 Feb 27 14:23 test4


That results in a file created with mode 022. I don't think that's what you are after. :)

[caveman]

Yep - you right Void

Sorry gang - this is what happens when you think about one thing
while writing something else

It should read "mode" and not "mask" - allthough they are related,
they are really not the same thing.
I mean - we use chmod to change permissions and not chmask - heh heh!

A lack of concentration - and we might really stuff things up....

[Void Main]

I notice that umask now also has a "-S" parameter that will show you the resulting symbolic mode. You can also use this to set your mask which would be easier if one has a hard time grasping what a mask is. For instance, my default mask is 0002:

Code: Select all

$ umask
0002


If I add the "-S" parameter I will see the resulting permissions I can expect to see on new files that I create:

Code: Select all

$ umask -S
u=rwx,g=rwx,o=rx


What this means is that new directories will have drwxrwxr-x for permissions (directories need the executable bit set in order for you to be able to change directory (cd) into them). New files will have -rw-rw-r-- permissions. You can also set your mask using that notation:

Code: Select all

$ umask -S u=rwx,g=rx,o=rx


I could have done the same thing with:

Code: Select all

$ umask 022