Linux - running scripts as another user

Content Authoring
1

I’m working on automating our shut down and start up procedures for our customer’s in-house software applications. All the shut down scripts they have in place now must be run as oracle and I need to run them as oracle or I will run into problems. A quick Google search turned up this:

"Path/to/script.ksh" -s /bin/ksh oracle

Would this work within an action script? I’m not a Linux junkie and rarely have a chance to use it so I have to make a suggestion and I want to be sure it would work in an action script.

2

Does that command work when you execute it as root? Whether it’ll properly impersonate the Oracle account depends on the script content (what’s it doing with those command-line parameters) and the permissions on the script/binaries themselves (setuid files being used?)

Generally, if it works as root, it should work with an actionscript. But I’ve had weirdness with quoted commands in ‘waithidden’, so I’ll usually use ActionScript to build a very small shell script, and then execute the shell script through

waithidden /bin/sh myscript

  • ps. don’t forget to chmod u+x the script file
3

Doh, left off the ‘else’.

If that command does not run right as root, you should be able to prefix the command with
su - oracle /path/script.ksh
to have root impersonate oracle when running the script.

4

If you’re executing scripts on Linux keep an eye out for the environment.
Your environment, when running via the agent, is likely to be different to that you get when you log in interactivley.
Have a look at this tip BES Client’s environment on *NIX

5

Very good to know, @gearoid.

The line I ended up using for my scripts was the following:

wait su - username -c "/path/to/script.ksh"

It seems to work the way I’d like so far.

6

Very true @gearoid
The environment is different often than root too due to when the agent starts in the boot process. Generally it is the generic base environment for the system. This is hard to see because if you run qna you will get the environment of the user running qna and not that of the client.

This often causes interesting side effects as the locale of the client might be different. This is becoming less of an issue as it is now more common on Linux distros to be UTF8.