"su -" from non-root to non-root same user without pw ?

[Kasper_USB]

on tru64 i can make a

su - username

from username (same account, nonroot-user) without to give the password.

can i do this too in hpux ?

if not why not ?

Thanks and regards

Olaf

[Ganesan R]

Hi Kasper,

No. You can't. HP-UX will ask the password even if you switch to same user.

>>if not why not ? <<<
Yet to find the reason :(-

[James R. Ferguson]

Hi Olaf:

Unless you are 'root' then 'su' will require the account target password on HP-UX.

Regards!

...JRF...

[Doug O'Leary]

Hey;

As others have pointed out, no you can't do this exactly as you're describing. You can get the same affect, though, by using ssh/public key authentication. There should be plenty of posts in itrc on how to set that up.

Doug O'Leary

[OldSchool]

Curious as to why you would *want* to do that tho

[Doug O'Leary]

Hey;

The big reason, as always, would be convenience. Specfic example: SAP. su'ing from ora${sid} to ${sid}adm and back again to support oracle and the SAP instance as needed...

I'm sure there are 1000s of other examples.

Doug

[Dennis Handly]

>from username (same account, nonroot-user) without to give the password.

You can use rlogin or remsh (with .rhosts) or ssh.

Otherwise there is no reason to use su from yourself to yourself.

>Doug: su from ora${sid} to ${sid}adm and back again

Once you su, you are not yourself. In your case, you could always exit.

[OldSchool]

right.....but the case mentioned is su'ing from himself to himself, while yours is between two non-root accounts, as in

login me

su - me

hence, my continued confusion

[OldSchool]

Dennis snuck in before me. the OPs case seems to be:
login:me



su - me

which I can't see any use in, hence my continued confusion.

while Doug's example is between to different non-root users (which I had thought about)

[Kasper_USB]

thanks for the many feedbacks.

for all who needs a explanation of the backround of my question:
we use a custom applikation startup script on system start. in this script we use multiple su's to a specific application user with his application environment and start a process in backround with nohup. now we have the need that this unprivileged application user needs too this script to start and stop his processes.

schematic example:
su - appuser "nohup /path/programm1" &
su - appuser "nohup /path/programm2" &
su - appuser "nohup /path/programm3" &

[Suraj K Sankari]

Hi,

With in the script you can provide username and passwd for login into some specific user but its a security violation.

Suraj

[Dennis Handly · Accepted solution]

>now we have the need that this unprivileged application user needs too this script to start and stop his processes.
>su - appuser "nohup /path/programm1" &

I suppose you could test if already appuser then do:
if [ "$(id -un)" != appuser ]; then
su - appuser "nohup /path/programm1" &
...
else
nohup /path/programm1 &
...
fi

[Doug O'Leary]

Ah;

I didn't quite catch that the user was trying to su to his own account. My bad.

To the OP, the answer to your question is sudo. Provide sudo privileges to the appropriate users for the init script then the users so configured can run the script as root. Root can su to any account without a password.

The command syntax for the appuser would be:

sudo /sbin/init.d/app_init_script [start | stop ]

Run visudo and add the appropriate lines - something like the following should do the trick:

User_Alias APPUSER = ${user1}, ${user2}
Cmnd_Alias APPINIT = /sbin/init.d/app_init_script
APPUSER ALL=(ALL) APPINIT

*That's* how you get around that little issue.

Hope that helps.

Doug O'Leary

[OldSchool]

I think Dennis has the cleaner solution. Check to see if your the specific "appuser", or root (since its a startup script)....

if you're "appuser" then run the commands w/o su, if you're not, then su as always

[OldSchool]

just beware that there may be permissions issues w/ other things within the script.. for example if root starts it and writes the PID to a file, and appuser tries to stop it, it may not be able to delete the pidfile. that kind of thing...

and sudo will indeed work, as you can run that script as root and it won't care about the su's