Each file in UNIX can be subject to three
operations - reading, writing, and executing. Every file has an
owner. The permissions are defined on three sets of users - the
owner of the file, the other members belonging to the group to which
the file belongs, and finally, the rest of the users of that server.
The permissions of a file are represented in UNIX via a set of
letters. If the following commands are given
The first set of columns containing the letters
r, x, and w - denotes the permissions of the file named osh. Let's
dissect the permissions string to decode what it means.
The first character denotes the type of the
file. In this case this is a "-", indicating the fact that the file
is a regular file. If this were a directory, this column would have
shown the letter "d".
owner of the file, the user oracle, has the
permission to read, write, and execute it.
The next three characters show the permissions
given to the group. In this case, they are "r-x", and it indicates
that the members of the group DBA (which is the group of the file)
can read and execute the file but cannot write to it.
The last three characters show the permissions
given to the rest of the users (sometimes called world permissions).
In this example, it shows "r--", which means the users have only
read permission on the file, not write and execute.
Another special type of permission exists,
called the Set User ID Bit (SUID). Let's see how this works.
Sometimes the owner of a file needs to operate on other files owned
by it, or to modify processes it started. This owner may want to
allow other users to perform the same tasks, but not give them
special permission for all of these files and processes. Instead,
the owner may set a special flag to indicate that the execution of
this file by another user should be as if he or she is executing it.
An example is the executable file oracle, which
is executed on behalf of the user who is connected to the database.
This special flag is called a Set User ID Bit. If this is set, the
permissions look like this.
-rwsr-s--x 1
oracle dba 82292320 Mar 17 16:12 oracle
Note the letter "s" in
the third place on the permissions for both the user and the group,
where the letter "x"
Should have been. For the user permission, this
simply indicates that the user executing the file will execute it as
per the permissions of the owner of the file, oracle. Similarly, for
group permission, the group owner's permissions are set at runtime.
This SUID permission is extremely powerful and
should not be granted lightly, in fact, it should be avoided if
possible. The Oracle installation itself puts SUID on some files in
the bin directory under Oracle Home. Find these files by running the
following command
ls – l|grep
rws
Examine these files and determine if the SIOD
is necessary as per the following chart. All these files are in the
$ORACLE_HOME/bin directory.
|
FILE |
OWNER |
EXPLANATION |
|
oracle |
The Oracle software owner, typically oracle |
This is the Oracle executable used by
sessions to connect to the database. The SUID should be set. |
|
dbsnmp |
Root |
This is an executable file for the Oracle
Intelligent Agent. This is used by the Enterprise Manager as its
agent process. If the agent is not utilized, then the suid on
this file should be unset. |
|
oidldapd |
Oracle |
This is the executable daemon for the
Oracle Internet Directory (OID). If OID is used, then the SUID
should be used, otherwise the SUID should be unset. |
|
onrsd,
namesctl
|
oracle |
These are files used by Oracle Name Server.
If Name Server is not used, then these files do not need to have
the SUID set. |
Table 4.1 Files with SUID turned on
Other than the files
listed above, there should be no other files with the SUID bit
set. If any file is found, immediately unset the SUID bit.
|
Download your Oracle scripts now:
www.oracle-script.com
The
definitive Oracle Script collection for every Oracle professional DBA
|
