50

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?

George M
  • 13,959
please delete me
  • 2,539

3 Answers3

51

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?

Community
  • 1
George M
  • 13,959
  • 9
    Good 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. – Marty Fried May 02 '12 at 02:17
15

The usual place to put your own scripts is ~/bin, and then add this directory to your PATH.

Renan
  • 17,136
  • I suppose on Arch the preferred location would be ~/.local/bin. – progonkpa Dec 25 '21 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. – Daniel Apr 24 '22 at 12:01
1

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

Kusalananda
  • 333,661
  • 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. – cde Mar 04 '20 at 01:36
  • @cde The point of /usr/local has 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 $HOME break existing services? On systems where service accounts are properly separated for security reasons, chroot jails are used. When a service is chrooted, accessing /usr/local isn't possible anyway. – Kusalananda Mar 04 '20 at 06: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. – cde Mar 04 '20 at 06: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 Mar 04 '20 at 06:50
  • Its kludgy at best and a backdoor at worst. – cde Mar 04 '20 at 07:08
  • @cde So a compromised service account would be less dangerous if it did not have read access to your $HOME/local/bin directory? Also, in what way would putting a personal script used by a service account into /usr/local/bin not provide a backdoor if putting it under your home directory would? I'm also interested in knowing what type of services you're concerned about. – Kusalananda Mar 04 '20 at 07:17
  • Attacker somehow gains access to service account. Service account has access to user's files. No privilege escalation required. – cde Mar 04 '20 at 07:26
  • @cde You would obviously still use sane permissions on files that needs to be protected. That goes without saying in any situation. I'm also still interested in knowing what type of external services you think would reasonable have access to personal scripts in /usr/local/bin. – Kusalananda Mar 04 '20 at 07:50