LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   AIX (https://www.linuxquestions.org/questions/aix-43/)
-   -   ksh scripting (https://www.linuxquestions.org/questions/aix-43/ksh-scripting-653273/)

lqchangba 07-03-2008 03:05 AM

ksh scripting
 
i used su - abc command in script and i dont want to pass password on the terminal. i want to pass the password from the script only (non interactive) what can i do

Mr. C. 07-03-2008 03:17 AM

Don't use su to do this.

Typically, you run the entire script as in :

su myscript

but that brings security concerns of course. This is the time when the standard question comes up - what are you actually trying to do?

custangro 07-03-2008 10:19 AM

Quote:

Originally Posted by Mr. C. (Post 3202639)
Don't use su to do this.

Typically, you run the entire script as in :

su myscript

but that brings security concerns of course. This is the time when the standard question comes up - what are you actually trying to do?

MR. C is right; we need more information if you want help...

But if you want to run a process as a user use su -c

For example to start postgres as the postgres user...
Code:

#!/bin/ksh -fuh
#
su - postgres -c "/usr/local/pgsql/bin/pg_ctl -D /var/pgdata start"
#
#

-C

b0redom 07-04-2008 06:45 AM

You're creating a MASSIVE security hole here. If you need root priviledges, why don't you just run the script as root, then you don't need to su at all?

custangro 07-04-2008 11:01 AM

Quote:

Originally Posted by b0redom (Post 3203855)
You're creating a MASSIVE security hole here. If you need root priviledges, why don't you just run the script as root, then you don't need to su at all?

What about processes that need to run as a specific user? Like postgres....mysql...?

-C

Mr. C. 07-04-2008 12:48 PM

System daemons that are started as root, have code built in to reduce their access rights as soon after startup as possible, whenever possible. These programs are scrutinized, and typically follow best-practices for setuid/setgid programs.

There has been several security issues with setuid/setgid Shell scripts. It has been considered a risky practice even to this day; the reason for it is simple. The shell interpreters have not generally focused on being security cautious, and programmers are not aware of all the ways a script can go awry.

Binary setuid/setgid programs (eg. from compiled C source) are inherently more secure than scripts, because the language does not have all the built in wildcarding, and other shell niceties designed for assisting humans. They have a limited, strict set of system calls that can be used, and their actions are entirely designed by the developer to permit only a single, or limited action.


All times are GMT -5. The time now is 05:32 AM.