7

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.

0
5

I'm surprised nobody has mentioned binaries that run with special privileges. Wireshark comes with a real-world use case here: one of its main functions is capturing network traffic, something that normally only root can do. It makes sense that you might want to allow certain users to capture traffic with Wireshark without having to give them full root access, so Wireshark comes with a binary called dumpcap that has the necessary capabilities (CAP_NET_RAW and CAP_NET_ADMIN) enabled. This binary is 0754 (rwxr-xr--) and its associated GID is a special group that Wireshark installs. This way, any user in the group can run the binary (generally through Wireshark) to capture traffic, and it will run with the necessary privileges to do so, but a user not in that group won't be able to because they wouldn't have execute permission. They could still copy it to their home directory, but then their copy wouldn't have the necessary capabilities set, so it couldn't actually capture any traffic.

2
  • thank you for answering my question! i just spent some time reviewing my question I had 6 years ago and all the answers here and I feel like this is pretty much what I wanted. I just learnt the capabilities are associated with a binary at a specific path and cannot be copied along with copying binary content. – woodings Oct 8 '18 at 0:52
  • 1
    "Capabilities" didn't exist when Unix permissions were invented. The classic Unix analogy is the setuid bit. Like these capabilities, the setuid bit will not be propagated to a copy. If you copy a root-owned executable, it will be owned by you. You can set the setuid bit, but then that file will execute as you, not as root. Nobody mentioned setuid or anything of its ilk because the question is about the execute permission. – Kaz Oct 9 '18 at 5:09
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...

2
  • 7
    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
  • It doesn't make any difference. It's not like a regular *nix user can't make any old file executable just by setting the executable bit anyway, same as a regular Windows user can rename a file to .exe and try to run it. And besides that, Windows does have a permission for execute. – Clonkex Aug 14 '20 at 5:19
4

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).

2
  • 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
1

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.

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

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/foo.sh
-rwxr--r-- 1 root root 890 2012-02-17 21:09 /usr/local/sbin/foo.sh

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

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 foo.sh 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.

0

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

1
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.