Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

share|improve this question

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
    
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 at 13:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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