su with password in a script.

[Chris Tijerina_2]

Does anybody know how to su within a ksh script? The kicker is that the user that I need to su into has a password. How do I put that into this script, I do not want to run as root, can this be done?

[Sanjay_6 · Accepted solution]

Hi Chris,

If the script is run as root and you are su 'ing to a user you don't have to give the password though the user may have a login password.

Hope this helps.

regds

[James R. Ferguson]

Hi Chris:

You can't do this in a simple shell script. The 'su' (unless you are root) will prompt you via your terminal, for a password.

You could use 'expect' however. See here:

http://hpux.cs.utah.edu/hppd/hpux/Tcl/expect-5.31/

Regards!

...JRF...

[harry d brown jr]

If you are trying to execute commands from cron, then each user can have their own "crontab" files.

Also, you can use the setuid bit on the script.

chown username scriptname
chmod 4555 scriiptname

live free or die
harry

[Chris Tijerina_2]

This script is not running as root. Can I su as user A and su to user B and have the script give the password for user B? Hope I am making sense.

Thanks
ct

[Sanjay_6]

Hi Chris,

I guess using expect you can do that. su to A, then su to B and give password. I haven't used the same myself, but it works interactively with the script.

Hope this helps.

Regds

[James Beamish-White]

su does not allow scripted passwords.

Why don't you run a blanket script from user root, running first script A, then B? Or if the su you are trying to do is in the middle of a script, break it up into 3 scripts?

i.e.

#!/bin/sh
# Run this script as root

su - user1 -c "/your/path/here/scriptA.sh"
su - user2 -c "/your/path/here/scriptB.sh"
su - user1 -c "/your/path/here/scriptC.sh"

Cheers,
James

[harry d brown jr]

I hate doing this, but here is another HACK:

in userB's home directory create a ".rhosts" file

.rhosts
userA

then as userA

remsh -l userB <scriptname>

live free or die
harry

[Tim Nelson]

Here is a thought depending on what you are looking for. If you are just looking for "file" permissions in order to run a script try setting the suid bit for user A and allow user B to run that script. Effectively the script will run as user A with their file permissions. Once again it all depends on what you are looking for in your out come. Beware of what user A can do with the script.

[Darrell Allen]

Hi Chris,

Soapbox time!

Personally and for security reasons, I don't like the idea of a script (or any file) containing a password in clear text. Neither should any user know another user's password. Granted, some group of users (dba for example) need to know a password for a common account (perhaps oracle) but that account should only be accessible by su'ing to it.

Users should have passwords. Don't even think of removing it.

Harry's remsh hack can be done but unfortunately it is effectively the same as giving userA the password for userB because userA could "remote" log in as userB any time he wanted to. You no longer have any accountability. Auditors don't like that kind of stuff.

The only secure solutions I see:
1. Give the user permissions to do what needs to be done so that he no longer needs to su.
2. Run the script as root.
3. Best choice I believe and as indicated by others - suid script.

Don't use 4555 because that would let anyone run the script. 4550 with the group being a secondary group for only the user(s) allowed to run the script should work.

Told 'ya I was on my soapbox! These are my opinions and are guaranteed to be different from the opinions of many other admins!

Darrell