Linux/Unix Compare File or Folder Permissions

Last night , in exadata machine , file permissions accidentally changed recursively with "chmod -R 777  /u01"  command.Therefore oracle binaries ,especially "s" bit permission, didn't work.First of all , scan listener crashed with "TNS no listener" error  in cluster, after that cluster rebooted and instances didn't start.So we decided to compare oracle binaries with other exadata machine for fastest solution.

Original permissions oracle binary
--------------------------------
-rwsr-s--x 1 oracle dba 232399123 Jun 21 09:30 oracle

find /u01 -type d -printf "%P\n" -exec stat -c "%a %n" {} \; | sort > file1.txt  (wrong permissions in exadata)

Copy file1.txt through scp to right machine .

find /u01 -type d -printf "%P\n" -exec stat -c "%a %n" {} \; | sort > diff - file1.txt (right permissions in exadata )

Also  , you can correct binaries permissions with $ORACLE_HOME/bin/relink all" command . It doesn't correct all files and directories , it makes changes in binaries and some files . But it is enough to work properly for oracle database.


Also you can find additional information http://docs.oracle.com/cd/E19082-01/819-3321/secfile-69/index.html

setuid Permission

When setuid permission is set on an executable file, a process that runs this file is granted access on the basis of the owner of the file. The access is not based on the user who is running the executable file. This special permission allows a user to access files and directories that are normally available only to the owner.

For example, the setuid permission on the passwd command makes it possible for users to change passwords. A passwd command with setuid permission would resemble the following:

-r-sr-sr-x 3 root sys 28144 Jun 17 12:02 /usr/bin/passwd

This special permission presents a security risk. Some determined users can find a way to maintain the permissions that are granted to them by the setuid process even after the process has finished executing.

---

Note –

The use of setuid permissions with the reserved UIDs (0–100) from a program might not set the effective UID correctly. Use a shell script, or avoid using the reserved UIDs with setuid permissions.

setgid Permission

The setgid permission is similar to the setuid permission. The process's effective group ID (GID) is changed to the group that owns the file, and a user is granted access based on the permissions that are granted to that group. The /usr/bin/mail command has setgid permissions:

-r-x--s--x   1 root   mail     67504 Jun 17 12:01 /usr/bin/mail

When the setgid permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs. The files do not belong to the group to which the creating process belongs. Any user who has write and execute permissions in the directory can create a file there. However, the file belongs to the group that owns the directory, not to the group that the user belongs to.

You should monitor your system for any unauthorized use of the setgid permission to gain superuser capabilities. A suspicious permission grants group access to such a program to an unusual group rather than to root or bin. To search for and list all files that use this permission, see How to Find Files With Special File Permissions.

Sticky Bit

The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the file owner, the directory owner, or by a privileged user. The root user is an example of a privileged user. The sticky bit prevents a user from deleting other users' files from public directories such as /tmp:

drwxrwxrwt 7  root  sys   400 Sep  3 13:37 tmp