5

I'm writing a bash script that does a little house-cleaning for me (clearing the log files from any Rails projects in the current directory). I'm making it executable, and I'm not sure what best practice dictates as far as setting the "group" and "others" file permissions. Should I just set permissions to 700 (only the owner can rwx)?

Part of my confusion is how "ownership" is determined when a file is copied from one system to another. If my UID is 509 and I set my_file.sh file-permissions to 700, I'm guessing the file-ownership is determined by storing a UID on the file. If I share my_file.sh and someone downloads it to their system, does the UID get changed to match their own? Does it depend on how the file is transferred (scp, git, http, etc.)?

1 Answer 1

6

I'm not sure what best practice dictates as far as setting the "group" and "others" file permissions.

A normal approach would be 755, so group and other have read-execute permission. Pretty much everything in (e.g.) /usr/bin is set that way.

If I share my_file.sh and someone downloads it to their system, does the UID get changed to match their own? Does it depend on how the file is transferred (scp, git, http, etc.)?

Almost certainly it does get set to their UID, but there are methods that can retain the original value -- for example, if you tar the file and then open it somewhere as root, you get the original numerical UID.

There's generally no significance to that, however, unless you have some particular reason you want to deploy the file somewhere with a specific UID. If your concern is about the ability to read and modify the script, there's no way to prevent that regardless of what UID or methodology you use. Someone who transports a file to another system where they have root access can do whatever they want with it. However, they cannot replace or modify the original unless they have write permission on the original.

On the local system, a file with read-execute permission can be copied (since it is readable) and the copy will have the UID of the user who made the copy. You can set a file executable but not readable, but there is no purpose in doing so; a file must be executable and readable in order to be executed. In other words, if you want everyone to be allowed to use the script, you need minimally world read-execute permission on it.

1
  • Great answer, thanks! In retrospect, 755 makes perfect sense. My concern wasn't preventing someone from modifying the script, just setting something that made sense for a shared executable. The fact that I wasn't sure what those settings were made me realize there were a couple more fundamental questions I had, such as how permissions are handled during file-transfer/copy. Your answer, plus reading a bit more about umask, helped firm up my understanding quite a bit :)
    – ivan
    Sep 1, 2014 at 13:52

You must log in to answer this question.

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