I decide to continue the serie with some ideas about the security. For the test purposes security is not so important, but for production and related (preproduction for example) this is considerable point.
On the previous post i use just plain command line and all the valued parameters as username and password are visible in command line:
[oracle@rh-or ~]$ sqlplus -S romeo/pass1234@orcl @date.sql "Today is "
So everyone who have access to the server can see them. If I try to use other technique to try to hide them with environment variable like this:
[oracle@rh-or ~]$ O_USER=romeo
[oracle@rh-or ~]$ O_PASS=pass1234
[oracle@rh-or ~]$ sqlplus -S $O_USER/$O_PASS@orcl @date.sql "Today is "
this will hide information from command line, but it is still visible via environment parameters of the process. For example in Solaris command pargs will provide such information
(https://unixswing.blogspot.com/2018/09/solaris-commands-for-process-management_22.html)
Lets rewrite the script with some inline code
sqlplus -S /nolog << EOD
connect romeo/pass1234@orcl
@date.sql
exit
EOD
The above script will expose in process list only fact of run sqlplus and nothing more. The rest of the information will be "entered" like in interactive session w/o any traces for other users.
Be aware that in the last line of code (word EOD) you should have no other symbols except mentioned word. Otherwise the script will not work on expected manner.
The rights of such script should be set to 700 to avoid disclosure of sensitive information to the extraneous. The only issue is you cant hide the information in script from the user will run it because in UNIX/Linux shells if you want to execute script you should have right to read it.
Showing posts with label scripts. Show all posts
Showing posts with label scripts. Show all posts
My best friend - cron
I love cron, but there are few details missed from most of the users:
1. It's wise to set only one command to be executed, do not play with one long line, just a little script. This will help to avoid errors and problems.
2. Force set environment variables you need for script. Script run by cron have very limited set of variables. Better add as first line of script:
. /my/home/.profile
or startup file for your shell (.bash_profile for example if you use bash as default shell)
3. As first line in your script set shell need for execution, do not rely on default one. This is named shebang and here you can find very good explanation what is this and how to use it.
4. Do not play with tricky sets of minutes, hours, etc. Use full citation, this will work on all UNIXes and Linux and give much better visibility:
0,10,20,30,40,50 * * * * /path/myscript
5. Be careful when you use the days of week. Beside other time variables which "use" AND as logical function between them Day of week use OR to the day of month.
1. It's wise to set only one command to be executed, do not play with one long line, just a little script. This will help to avoid errors and problems.
2. Force set environment variables you need for script. Script run by cron have very limited set of variables. Better add as first line of script:
. /my/home/.profile
or startup file for your shell (.bash_profile for example if you use bash as default shell)
3. As first line in your script set shell need for execution, do not rely on default one. This is named shebang and here you can find very good explanation what is this and how to use it.
4. Do not play with tricky sets of minutes, hours, etc. Use full citation, this will work on all UNIXes and Linux and give much better visibility:
0,10,20,30,40,50 * * * * /path/myscript
5. Be careful when you use the days of week. Beside other time variables which "use" AND as logical function between them Day of week use OR to the day of month.
Subscribe to:
Posts (Atom)