Problems with Oracle's inability to SU-switch

Client an Oracle suddenly when the machine, because the business start-up, the customer subconscious reboot the server, the system is up, ready to switch to Oracle users to start the database, can not SU switch, it is really to add to the description as follows:

Under Root, Su to an ordinary user, Oracle, gets the following error:

[Root@localhost ~]# Su-oracle

Su:warning:cannot Change Directory To/home/oracle:permission denied

SU:/bin/bash:permission denied

The same error is not possible with Oracle users logging on directly.

This is a very strange question, what is the cause of it? Ideas are as follows:

1, program execution permissions issues

2, program-dependent shared library permissions issues

3, Directory Permissions issues

4, root space problem.

Check/bin/bash, permissions are correct, check/home/oracle permissions correctly, check/lib/ld-***.so, permissions are correct.

Continue debugging, check/etc/passwd, set Oracle home to/TMP, SET/TMP to 777, and this should be the most relaxed permission.

The same error occurred with Su.

That is, the/TMP for which Oracle users cannot access 777 permissions.

Where did the problem come from?

At last

Through the Star command, see the root of the problem,

[root@localhost ~] #stat/

The output is as follows: Because you are not invisible to LS.

File: "/"

size:1024 blocks:2 IO block:1024 Directory

device:803h/2051d Inode:2 links:22

Access: (0666/drw-rw-rw-) Uid: (0/root) Gid: (0/root)

access:2007-12-01 22:28:48.000000000 +0800

modify:2007-12-01 22:28:34.000000000 +0800

change:2007-12-01 23:17:35.000000000 +0800

The problem is, the permissions here are wrong, and the loss of x permissions is the cause.

[root@localhost ~] #chmod 755/

After the change, the problem disappears.

Methods to produce the above problems:

The first type, chmod 666/, can lead to.

Or

The second type, chmod 700/lib/ld-xxxx.so, can also cause Su to fail.

Be interested to try it on your own.

/permission loss has the same effect on various daemon that run on their own user identity.

This article is from the "Technology Achievement Dream" blog, please be sure to keep this source http://ixdba.blog.51cto.com/2895551/526427