8

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.

Improve this question
0

6 Answers 6

Reset to default
6

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.

Improve this answer
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, 2018 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, 2018 at 5:09
12

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

Improve this answer
2
  • 8
    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, 2012 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, 2020 at 5:19
5

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

Improve this answer
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, 2012 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, 2012 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.

Improve this answer
1
  • What you're missing is that a file can be executable but not readable.
    – Keith Thompson
    Mar 29, 2012 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.

Improve this answer
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

Improve this answer
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, 2012 at 23:31

You must log in to answer this question.

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