From what I understand, the right place to put your own scripts is /usr/local/bin (for instance a script I use to back up some files). I notice that this folder is currently (by default) owned by root, and my normal user has no access to it. I am the only user on this computer. Shall I change this whole folder to my own user? Or is there another proper way to arrange permissions of /usr/local/bin?
asked May 1, 2012 at 18:29
Add a comment
|
3 Answers
By default, the owner and group of /usr/local and all subdirectories (including bin) should be root.root and the permissions should be rwxr-xr-x. This means that users of the system can read and execute in (and from) this directory structure, but cannot create or edit files there. Only the root account (or an administrator using sudo) should be able to create and edit files in this location. Even though there is only one user on the system, it's generally a bad idea to change permissions of this directory structure to writable to any user other than root.
I would suggest placing your script/binary/executable into /usr/local/bin using the root account. It's a good habit to get into. You could also place the script/binary/executable into $HOME/bin and make sure $HOME/bin is in your $PATH.
See this question for more discussion: Where should a local executable be placed?
-
9Good answer; I thought maybe I'd add my 2 cents worth. Even if you are the only user now, this could change in the future, and it's a good idea to follow best practices all the time. If you have a personal script only for yourself, put it in ~/bin; if it's something others might use, put it in /usr/local/bin. Others could mean yourself, in a different account, too. And, remember, some of the rules protect you from yourself, to make it harder to delete important files. Commented May 2, 2012 at 2:17
The usual place to put your own scripts is ~/bin, and then add this directory to your PATH.
-
I suppose on Arch the preferred location would be ~/.local/bin. Commented Dec 25, 2021 at 15:26
-
In Ubuntu these can be added to
~/.local/bin. The directory wasn't in my path, but once I placed a binary there and rebooted it appeared on the path without having to do anything.– DanielCommented Apr 24, 2022 at 12:01
Since you are the only user on the system, and therefore the only user of the scripts that you write, I don't really see much point in installing personal scripts in /usr/local/bin. Installing scripts in /usr/local/bin would only make it more awkward to back up and to maintain your personal files.
Also, the /usr/local hierarchy may be used when installing external software from locally compiled source code, which means that software installed in that way have a potential risk of overwriting your personal scripts and/or accidentally pick them up as system-provided tools (depending on how you name your scripts).
Also note that package managers on some BSD systems install packages under /usr/local (OpenBSD and macOS, for example), which is another reason to leave that particular file hierarchy alone for personal scripts.
If you're the only user of the system, then just install under $HOME, for example in a $HOME/local hierarchy. Either that, or use a totally separate hierarchy rooted in, e.g., /opt or /sw or somesuch place (not used by base system or package managers).
answered Jan 1, 2017 at 11:28
-
Just because you are the only user doesn't mean it should be in home. Plenty of non-user service accounts/users as a security feature for privilege minimizations. Installing in $home would break that. And that's the entire point of /usr/local/, more so then /opt would be.– cdeCommented Mar 4, 2020 at 1:36
-
@cde The point of
/usr/localhas to do with separation of locally maintained software from software maintained by the distribution provider. It is not primarily a security feature. Also, exactly how would installing software under$HOMEbreak existing services? On systems where service accounts are properly separated for security reasons, chroot jails are used. When a service is chrooted, accessing/usr/localisn't possible anyway.– Kusalananda ♦Commented Mar 4, 2020 at 6:17 -
Because installing in $HOME would mean whatever service OP is using would need to be ran under a user that has permission to access and execute from op's $HOME. So now you have to change group memberships or leave $HOME with more permissive permissions, etc.– cdeCommented Mar 4, 2020 at 6:41
-
@cde What would be the exact issue with allowing a service account to read files associated with a personal script from your home directory?– Kusalananda ♦Commented Mar 4, 2020 at 6:50
-