Some clarification

[Chris Elmore]

Maybe I'm being lazy and maybe I am unaware of the security repercussions, but I figured if I can run someone else's profile from the command line then it should be no different syntax-wise in my shell script, and I can just paste that into the beginning of the script. I am running a shell script which runs Oracle SQLPlus but needs that .profile of the other user *before* I can get to the SQLPlus portion. I want to enable this script to run in cron under root, and I've seen where I can add this (oracle) user to the cron.allow file to cron it as that user, but I really wanted to have the cron run under root while just invoking the .profile to pick up the (oracle) environment parameters SQLPlus needs.

[John Poff]

Hi Chris,

You might want to post your reply back under your original question so we can follow the discussion under that thread.

Thanks!

JP

[James R. Ferguson · Accepted solution]

Hi (again) Chris:

Sourcing a profile to gain environmental variables is a poor choice. The profile is designed, by default, to run in an environment where 'stdin' is a terminal. When a profile is sourced in a crontask the usual result is a cascade of "not a typewriter" messages.

It is far better to place the environmental variables you may need (e.g. for an Oracle environment) in a separate file from the profile and to source the standalone file when needed. Indeed, you can even source the standalone file *within* your profile.

Regards!

...JRF...

[Ray Brewer]

In this case what you can do is call your script from within cron then in your script you can source that users profile by doing

". ///.profile"

or you can execute your command in your script by doing

"su - -c "

by using the "-" after the su it will execute the command using that users profile. To make it secure set the permissions of your script to 500 and put it where only root can get to it.

hope this helps

Ray

[John Poff]

Chris,

We have a lot of Oracle databases and we stop and start them as root, but we like to use the 'su - oracle -d /oracle/do_some_script' method. First, the script is owned and maintained by the Oracle DBAs, so they can change their environment and the script as they need to and they don't have to bother us (as long as the script runs). Also, the script (and the .profile) don't run as root, so an evil user can't put in some code to give themselves root access. From a sys admin standpoint, it is easier for me. If the script blows up and doesn't work, I just go to the DBAs and say, "Hey, fix your script!" :)

This method just follows the school of thinking that the less you do as root, the better off and safer you will be.

JP

[John Poff]

Oops. In my last post, I meant to say:

'su - oracle -c /oracle/some_script'

The -d was a typo, and it probably does something bad and ugly to the su command.

JP

[Chris Elmore]

I accidentally posted this as a new post when I intended to reply to my earlier post regarding this problem (My mouse finger zigged when I wanted to zag). My thanks to everyone who took the time to assist me and my apologies for the accidental post. The excellent replies I received helped me fix my problem. I intend to credit fully everyone who so generously helped me. Thanks again.

[James R. Ferguson]

...and this is the post to which he refers:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x09e0a848deccd61190050090279cd0f9,00.html

...JRF...