manage /opt folder permissions

Question

I'm asking how to manage the permissions of /opt folder and files/folders under it. At the moment, the /opt folder has the default configuration

drwxr-xr-x root root

However, I changed the permission of all the folders under it with

chown -R my_user_name:my_user_group /opt

and this is the output of

$>ls -Al /opt
total 44
drwxr-xr-x  3 tigerjack89 tigerjack89 4096 set 11 17:47 Adobe
drwxr-xr-x  3 tigerjack89 tigerjack89 4096 set 11 17:47 Adobe AIR
drwxr-xr-x 13 tigerjack89 tigerjack89 4096 ott  5 20:48 android-sdk-linux
drwxrwxrwx  8 tigerjack89 tigerjack89 4096 set 27 16:40 axis2-1.6.2
drwxr-xr-x  4 tigerjack89 tigerjack89 4096 set 11 17:47 Balsamiq Mockups
drwxrwxrwx  3 tigerjack89 tigerjack89 4096 lug  6  2013 _--_BRAND_--_
drwxrwxrwx  9 tigerjack89 tigerjack89 4096 ott  5 21:05 eclipse
drwxr-xr-x  3 tigerjack89 tigerjack89 4096 apr 25 16:11 google
drwxr-xr-x 16 tigerjack89 tigerjack89 4096 lug 17 19:50 jd2
drwxr-xr-x  3 tigerjack89 tigerjack89 4096 mag 28  2013 MATLAB
drwxr-xr-x 11 tigerjack89 tigerjack89 4096 set 30 12:50 Modelio 3.1

The main reason for this change is that I don't want these applications to run with superuser privileges. However, I don't know if this is the right thing to do. For example, to correctly run Google Chrome, I have to switch back chrome-sandbox to root:root; also, if I try to run the Android SDK Manager via /opt/android-sdk-linux/tools/android it fails to fetch some links and I have to run the previous command as superuser.

So, do I have to switch all the things back to prevent other issues?

Answer 1

There is a basic confusion here: the fact that an application is owned by root does not mean that is run as root at all.

When you run cat:

ls -l /bin/cat
-rwxr-xr-x 1 root root 47904 mar 24  2014 /bin/cat

you run it as your user, because your user (and all other users) can read and execute it. This is the reason why

cat /etc/passwd-

gives

cat: /etc/passwd-: Permission denied

(because only root can read that file).

The exception are "set-uid" executables; but if an executable is "set-uid" is because normally it needs it, like the sandbox you mention. If you do not trust a set-uid executable, the only option is not running it.

So changing the ownership of the files under /opt will not enhance the security, and can breaks all kind of things.(1)(2)

See also: How can you know if executing a program requires root?

---

(1) Well, you can do that in "controlled" way and it can be useful. If /opt is owned by you you can for example run the installer of Calibre as your user and not as root; mind you, the installer, because the program will run as you anyway.

(2) You can find all the set-uid (and set-gid) files under /opt with

find /opt -perm -4000 -o -perm -2000 -print 

in case you need to set them back to their original user (that normally is root, but not always; unfortunately there is no way to know which was before your chown -R short of looking at a backup).