Who should own files in /usr/local (and executables, libraries in general)?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Who should own files in /usr/local (and executables, libraries in general)?
Are there any conventions about setting up ownership and permissions on programs installed to /usr/local? For example, I have Firefox installed into /usr/local/firefox. Is there any disadvantage to setting ownership to a (the) regular user? Would there be any disadvantage to setting ownership to root?
I was able to run Firefox after assigning ownership of both the executable firefox, and the firefox libraries (*.so files), to the regular user. This can't work (I don't think?) on a multiuser system, though, so I wonder what the conventions are. I also wonder whether there are problems that I might not notice right away.
If for example a particular user owns /usr/local/firefox/firefox-bin, he can modify firefox-bin so that its trojaned, then when other users(or in the worst case root) executes it bad things can happen.
Normal users shouldn't own any system-wide binaries at all.
Firefox should be able to work with any user when it's files are owned as root with proper permissions set.
The /usr/local directories are only writable by root. Unless a program or library has a special owner setup by the installation, the owner will be root. Nothing would be gained by changing it.
The "problem" isn't as much a problem of the
ownership (even though files in global locations
would typically be owned by root since normal
users don't have write-permissions to those direc-
tories) but rather of permissions ...
if the files (executables & libraries) are set to
u=rwx,go=rx and u=rw,go=r respectively the
normal user is (should be) able to run the app.
There are no other users on this PC, that I am aware of. So, I am indifferent to the program's owner for maintenance purposes. I can always switch to root. But, clearly it is important that any programs I run as the regular user not be able to modify themselves or other programs. So I'll keep installing things as root.
Incidentally, this problem came about when I downloaded and installed Firefox. Made the firefox directory user-owned to download the installer there, and just installed on the user account also. In the future I will download to user directory, the log in as root to install.
You could 'su' to root instead. For KDE programs, there is kdesu.
The firefox installation was a bit goofy in my opinion. I changed the name of the directory from 'firefox-install' to 'firefox' in the installation program dialog. I also produced links to the 'firefox' and maybe the 'firefox.bin' files in the /usr/bin dir.
A previous installation of firefox installed much more smothly for me.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.