hi,
i have a requirement where i need to sudo to another user in the shell script.suppose consider user A and B, first user A calls a shell script and then i need to sudo to user B which executes another shell script inside the earlier one.
also this needs to be automated like while sudo'ing to user B it should not ask for password prompt, password should be read from some file or by any other means.i'm a newbiew , please sugggest steps for the above problem.

other than this is there any way around for my problem??? please suggest ???

There's no silver bullet for your problem. If compliant to your site's policy, you could disable the authentication requirement (cf. man sudoers):

Quote:

Authentication and Logging
The sudoers security policy requires that most users authenticate themselves before they can use sudo. A password is not required if the invoking user is root, if the
target user is the same as the invoking user, or if the policy has disabled authentication for the user or command.

You could use the -A option (cf. man sudo):

Quote:

sudo accepts the following command line options:

-A Normally, if sudo requires a password, it will read it from the user's terminal. If the -A (askpass) option is specified, a (possibly graphical) helper
program is executed to read the user's password and output the password to the standard output.

You finally could remove the reason why you need to switch to user B - adapt e.g. permissions of commands and files. Again, if compliant.

The "-u userb" flag tells sudo to run as the supplied user instead of root

Add the following line to your sudoers config file:

Code:

usera ALL=(userb) NOPASSWD: /full/path/to/anotherShellScript.sh

The "usera ALL" tells sudo that usera on any server (ALL) my run this command
The "(userb)" tells sudo that the command can only be run as userb (not the default of root)
The "NOPASSWD:" tells sudo not to prompt for usera's password like it normally would (unless otherwise configured elsewhere)

Some traps to watch for:

sudo does funny things with the environment, if your other shell script (the one being called as userb) is expecting environment variables to be properly set for userb, you might find it goes wrong. Things like PATH and HOME can surprise you.
I typically set any variables I need explicitly in the top of shell scripts being called by cron or sudo to prevent these issues.

If this is a big problem for you, you can add a layer of indirection and use "su - userb -c /full/path/to/anotherShellScript.sh" to have it load userb's environment before running the script.
Resulting sudo call in your first script would be:

Code:

sudo su - userb -c /full/path/to/anotherShellScript.sh

You would now be running the su - command as root, then having it in turn select userb.

The "(root)" bit isn't technically required, but I've done it that way to try and demonstrate what is changing between the two solutions.

As RudiC mentions, your company security policy will have an opinion (possibly a very strong opinion) on this. In some outfits, breaching this is bad enough to get you met at the door by security holding all your things in a black plastic rubbish bag ie, find out if it's cool to do this before you actually do it.

Be careful with the permissions on /full/path/to/anotherShellScript.sh and how well it's written as you've effectively made this script run with elevated privileges. If usera can find a way to change the content of this script, or if the script is written badly enough that someone can break out of it into a shell while it's running, you could be granting usera carte-blanc access to run things as userb (thus the security policy comment above). Assume the other users on the box and usera are all determined to destroy your server and/or bring down the company while writing the script and you'll have the appropriate level of paranoia.