Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I got an executable file with read-only permission (read and execute to root), I can always copy it to my home directory where I have full-control permission. Then I set the new file to read and execute. Okay, I can execute it.

Is it really necessary for a file mode? I know for directories it means different.

share|improve this question

migrated from Mar 28 '12 at 23:28

This question came from our site for professional and enthusiast programmers.

up vote 1 down vote accepted

The execute bit is somewhat confused between being a permission and an object type identifier.

And, no you cannot "always copy" the file to your home directory: only if it is readable to you.

Files can be executable to you, but not readable.

You're right in that if a file is readable to you but not executable to you, you can copy it and flip the execute bit and use it. Maybe. But it might not work. The executable may be sensitive to where it is installed. Or the file may depend on its setuid root bit.

I wouldn't design a permission system that way starting from a clean slate; it doesn't entirely make sense. The permission to execute would be separate from an executable type attribute, and execute permission would not be overloaded with search permission (even if it was stored that way; the API would not reveal it at the bitmask level).

share|improve this answer
It makes sense to consider it as an object type identifier instead of a permission bit. Then setting a file to executable to some users and non-executable to the rest of users would be really confusing. – woodings Mar 28 '12 at 23:37
Copying to your home directory would also not do anything useful if /home was mounted with the noexec option. – Zoredache Mar 29 '12 at 0:11

Because *nix isn't brain-damaged enough to make a file "binary executable" if you happen to name it ".exe" or "script executable" if you happen to name it ".bat".

In Linux, the name of the file doesn't matter.

And the permissions you give a file do matter.

Which kind of makes sense. IMHO...

share|improve this answer
You can argue it the other way too that Unix allows you to set a file executable without any visual cue that it is. Everything recent works on ACLs anyway. – JOTN Apr 4 '12 at 22:25

Thats a good point, and I think I see where you're heading with this.

To reinterpret your question : Is the following claim true - "Setting a executable to non-executable mode for a user does not limit the user's capabilities".

I think its true.

  1. Copy the file to some other directory.
  2. Change exec perms.
  3. Run from whichever pwd (in particular, the original directory) by giving full path to the new copy of the executable, with any command line args.

I don't think there's anything else missing, which you would have by having the original file's exec perm set on.

By pwd I mean present working directory.

share|improve this answer
What you're missing is that a file can be executable but not readable. – Keith Thompson Mar 29 '12 at 1:15

There are many reasons why you might wish to mark a file as readable but not executable, especially by certain users or groups. Consider the following:

# /usr/local/sbin/
-rwxr--r-- 1 root root 890 2012-02-17 21:09 /usr/local/sbin/

# ~/bin/
-rwxr-xr-x 1 user user 890 2012-02-17 21:09 /home/bin/

This could make sense if:

  1. The files are different--perhaps you've replaced every instance of "root" with "user" in the script--but your path contains /usr/local/sbin:/home/user/bin. The permissions will ensure that running will run the user's modified copy, even though root's copy would come first in the search path if its execute bit were set.
  2. The files are identical, but does something different at run-time based on its basename, parent directory, the calling user's home directory, or some other clever programming trick. In such cases, you want users to copy the file somewhere else before running it. A lot of example scripts remove the execute bit in order to force users to copy-and-customize.

Ultimately, nothing stops you from copying any file you can read, or even just running it directly with sh /path/to/file. The missing execute bit for your user or group just prevents you from doing it by accident. It's not a security measure, and shouldn't be taken for one.

share|improve this answer

From what I understand you want to know why a read-only-non-executable by you can be copied to your home directory where you can make it executable and execute it, thus creating the illusion that the "executable" bit is unneeded.

In your case it could be useful because the executable may work only in it's original location, so copying it to a new location and executing it will fail.

On the other hand, having your own home directory with full access there already grants you some level of confidence to the system. There are many situations where users only have read access in which case you could read the executable file but can't execute it in any way

share|improve this answer
Read but not execute doesn't seem like a very useful combination on an executable, but execute-and-not-read is useful. There is no way to have execute-and-not-read in fewer than two bits, so ... – Kaz Mar 28 '12 at 23:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .