HowTo "su aUser" as root and not require a password
 

I need to write a cron script that will run on a SunOS 5.9. it will be kicked off as "root".

The script will "su anotherUser" and then do a bunch of stuff under the environment of "anotherUser" (which is an NIS userID, it is not a local user; ie it has no entry in /etc/passwd).

Now, for RHEL and AIX systems, I have successfully run this as follows (from w/in a cron script) as:

0 2 * * * su aUser -c "/whatever/aCommand"

or

0 2 * * * su -c "/whatever/aCommand" aUser

depending on the shell and OS. It just so happens that for those systems the "su" command - when run as root - does not require that the password be interactively entered. (I have nothing to do with the administration of these systems).

However, on a particular SunOS 5.9 host, the "su" always requires that a password be given (the user I am trying to "su" to is in the /etc/sudoers file with NOPASSWD specified; tho i do not think this has any bearing on the issue).

I suspect I need to twiddle something in /etc/pam.conf? But I cannot figure out what (if in fact that is the thing to do).

Any suggestions out there?

tx,

rich

Greetings,

It has been a *long* time since I've had to mess with SunOS... Probably close to 10 years now. BUT, that being said, I think that if you want to accomplish running something as another user on a SunOS box, I think you need to use sudo to make it non-interactive.

HTH.

Sudo and su are entirely different things.

Sudo is an add on piece of software that references the /etc/sudoers file and allows ordinary users to run commands with root privileges.

su is the operating system command for changing users.

As root user in both Solaris 9 and Solaris 10, I routinely su to another user without using a password. I use this, for example, to set people's vacation messages when they aren't comfortable with the command line to do it themselves.

I also have scripts that use that syntax:

su - backup -c "ssh ${TAPESERVER} \"mt -f ${TAPDEV} rewoffl\"" ;

for example (where the user is "backup", and I really don't remember or care what I ever set the password to for that user).

So, the question here is what is happening for the system that rococo is dealing with? Does that happen on the command line as well as in cron? Have you got the syntax right? Are you sure that's running as root? I suppose it's possible that there is some non standard setting that prevents root from being able to su to a user without the password? I'm not familiar with any such setting; but, assuming rococo has checked out everything else, that's the direction to be looking for an answer. It's a slightly difficult thing to google for.

choogendyk is correct. my issue is not related to 'sudo'. i can "sudo" (as the non-root user in question) w/o entering a password b/c I set up /etc/sudoers for that non-root user with tht NOPASSWD flag.

To be very precise (where nru = a non-root username):

nru: sudo cat /etc/sudoers #succeeds w/o need for password

My problem is this:

root: su nru -c /an/nfsmount/bashScript.sh
passwd:

That is, I am executing the above "su" command as root wishing to run
the bashScript.sh file as the non-root user nru, who is an NIS username (not a local user found in /etc/passwd). [In fact, the basj script also resides on an NFS mount under directories owned by 'nru'; but that is beside the point I believe.] On the SUN platform, I am asked for nru's password, even tho it is root running the command! This behavior does not occur on two RHEL hosts and an AIX host.

I ran this on the command-line testing things out before I put the command in root's cron file. It never occurred to me it might succeed under cron control but fail as root in a command shell. I cannot believe that is the case, but I suppose I ought to try it.

I really believe the answer is in the PAM configuration. But I cannot figure out which of the many "login" configs effect that. I also need to know if there are additional side-effects were I to discover which PAM line to modify.

This should not be so difficult...Sigh...

It must be something about version 5.9. I just tried on OpenSolaris version
SunOS 5.11 and it works as expected.

You might want to see if there are any updates for the package containing
su. Also check if there are more than one executables named su.