Why should I be installing my applications in the /opt location?

Question

I don't quite understand why /opt is recommended for 3rd-party software. I have to use sudo when I run my programs from /opt via the command line. Doesn't that provide a security risk since sudo allows the program to run as super user?

I am also having trouble adding a .desktop file to a program in /opt. For example if I have a .jar file in opt I have to run it with sudo java -jar name.jar to run the java program, but sudo & gksudo do not seem to work when in a .desktop file, so I can't execute the program from my launch menu without going through the command line.

Where should untrusted software be installed?

Where should applications that need a .desktop be installed?

Is there a way to make .desktop files run the application in /opt?

Solution

the documentation for the Linux file-system explains the history & purpose of /opt. the most common use is to setup applications, which run on their own, without having much dependencies to the rest of the system. "untrusted software" should not be installed at all; in case one has to, an hygienically isolated KVM container is ordinary to most safe way to do so.

This directory is reserved for all the software and add-on packages that are not part of the default installation. For example, StarOffice, Kylix, Netscape Communicator and WordPerfect packages are normally found here. To comply with the FSSTND, all third party applications should be installed in this directory. Any package to be installed here must locate its static files (ie. extra fonts, clipart, database files) must locate its static files in a separate /opt/'package' or /opt/'provider' directory tree (similar to the way in which Windows will install new software to its own directory tree C:\Windows\Progam Files\"Program Name"), where 'package' is a name that describes the software package and 'provider' is the provider's LANANA registered name.

Although most distributions neglect to create the directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man they are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the system administrator, but must function normally in the absence of these reserved directories. Programs to be invoked by users are located in the directory /opt/'package'/bin. If the package includes UNIX manual pages, they are located in /opt/'package'/man and the same substructure as /usr/share/man must be used. Package files that are variable must be installed in /var/opt. Host-specific configuration files are installed in /etc/opt.

Under no circumstances are other package files to exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files in /var/lock and devices in /dev. Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.

The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.

Generally, all data required to support a package on a system must be present within /opt/'package', including files intended to be copied into /etc/opt/'package' and /var/opt/'package' as well as reserved directories in /opt. The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution installed and locally installed software, especially in the case of fixed pathnames found in some binary software.

The structure of the directories below /opt/'provider' is left up to the packager of the software, though it is recommended that packages are installed in /opt/'provider'/'package' and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/ 'provider'/lib or /opt/'provider'/bin.

in case the default permissions won't suffice to run an application from /opt one can take ownership alike sudo chown -R $USER:$USER /opt/somepackage (this question has been asked over and over, maybe just search instead of asking). there are no rules, here I install much into /home/somecompany/somepackage directory, just because it has it's own partition and is being more frequently accessed than /opt, which is kind of relic from UNIX.

Comments

[Chai T. Rex]

Installing to /opt doesn't make a program require sudo to run. Either permissions for configuration files have been messed up or the program itself requires sudo to run.

[AlexP]

You absolutely do not have to use sudo to run programs from /opt. I have no idea why you believe this; maybe you have incorrect permissions on /opt? It should be owned by root:root with permissions rwxr-xr-x. And "untrusted software" should not be on your computer at all.

[Rhys]

I checked the permissions and the owner/group is root:root. I cannot create a text file, or run any of the programs in /opt as a user without running sudo first

[Panther]

linuxjournal.com/magazine/pointcounterpoint-opt-vs-usrlocal

[muclux]

You always need sudo when you install a package to /opt - that's why the system asks you for your sudo password when you install new software -, but generally not when you want to execute something from there.