I'm using a generic logging script from init:

exec sh -c "$*" 2>&1 | /usr/bin/logger -i -t `basename $1` -p info"

that i call like "syslog.sh oracle.sh" from another script installed with chkconfig.

oracle.sh performs

su - oracle -c "opmnctl startall"

init starts the logger, and i get a couple of messages in /var/log/messages, but then the su command blocks (I can see the su command with ps).

If I execute the exact same command interactively, it works fine, but from init, it blocks.

This also runs fine on AIX.

One thing I noticed is that I do get the "cannot relabel" pam selinux error when running interactively, but this is apparently normal.

Could it be that the su is simply blocked on asking for the password?
Try logging the output of "whoami" just before the su call.
If it says that you're root, then you can su without submitting a password. Otherwise, su will stop when it asks for a password.

If it does say root, maybe there's a problem with your PAM/SELinux settings or something.
Since you mention that it runs fine on AIX ( a Unix variant, if I'm not mistaken), SELinux might indeed be the cause.

As an alternative, you could also try creating script to launch opmnctl. Chown it to user 'oracle' and give it setUID permission bit. In such a case, the 'su' will become unnecessary.

illogical train of thought, sorry.....

Thanks timmeke.

I checked and id shows root just before the su.

Do you know a way to debug selinux or this script? How can I even tell what is happening?

If you're already running the commands as root, then su won't ask for a password normally.
But coming to think of it, root can run any command, including the opmctl command. So you could leave off the "su". Downside is that it'll run your command as root, rather than user "oracle".

Can you do an ls -l on the opmctl program? I'm guessing that there might be better alternatives than using "su" in this case. The SetUID permission bit, to be precise.

You may try running the command (su ...) in a subshell and catch all of it's output/error messages like this:
I'm no expert in debugging/disabling SELinux. Maybe you can search the security forum for answers on that?

You might also try sending "su" a signal to quit (run it in the background, then use $! to get the process ID of the command, followed by a "kill" command to send the signal). This should stop it from blocking everything, and may also log/show some error messages, but it probably won't properly execute the command you want it to.

Ahah!

That helped. It prints "Do you want to choose a different one? [n]" on stderr.

This is an seLinux question specific to redhat. They've integrated newrole and su... Now I have to find a way around this. I think using setuid is maybe the best, but I have to rethink things because some of the things need to be executed from root, some from Oracle.

Thanks for your help.

The solution is to remove the "multiple" option in /etc/pam.d/su

on the line

session required /lib/security/$ISA/pam_selinux.so open multiple

The docs say that multiple means:

"Tells pam_selinux.so to allow the user to select the security context they will login with, if the user has more than one role."