Alternatives to 'whoami' for scripts that run in background. Scripts are limited to specific user.

[Jack C. Mahaffey]

I see that has been talked about before. I need a workaround. I have scripts that have checks to permit execution by specific users. For example: I have database export scripts that I only want to be executed by either root or oracle. I may add other users at a later date. I want to use whoami to catch the login attempting to execute the script and decide to terminate early if the correct login(s) are not used. Output from whoami gives me this information when running in interactive mode. When the job runs in background, i.e. cron, I get the following:


Usage: who [-rbtpludAasHTqRm] [am i] [utmp_like_file]

r run level
b boot time
t time changes
p processes other than getty or users
l login processes
u useful information
d dead processes
A accounting information
a all (rbtpludA options)
s short form of who (no time since last output or pid)
H print header
T status of tty (+ writable, - not writable, x exclusive open, ? hung)
q quick who
R print host name
ttytype: couldn't open /dev/tty for reading


Is there another way to determine which login is attempting to execute the script in background?


Thanks in advance.

[Chris Watkins_1]

I'll answer the same as I did in the other thread where you brought this up... "id"


Something like this should work fine:


if [ ! `id -u` = 123 ]
then
USER=`id -un`
echo "Run permission denied for user " ${USER}
exit 1
fi

(Where 123 is the "correct" userid)


Admittedly, I haven't used this from a crontab, but
then again, I don't really have a reason to do that, in my case.

[A. Clay Stephenson · Accepted solution]

if [[ "${LOGNAME}" = "root" || ${LOGNAME} = "oracle" ]]
then
echo "You is okay"
else
echo "You ain't"
fi

[Patrick Wallek]

I would be tempted to go a complete different direction with this. I would change the ownership and permissions of the script so that only members of a single group, defined in /etc/group, could run this.

Create the group, make root and oracle members of it. Then change the ownership of the script to root with a group of new-group (or whatever you define) and then change the permission on the script to 550 and you are good to go.

[Jack C. Mahaffey]

Thanks to all for such speedy replies. Here's what I ended up doing. I created a script named ami.sh. Usage for script is:
ami.sh

If a match is found, 0 is returned, otherwise 1 is returned.

Here's the script contents:

#!/usr/bin/sh

BNAME=`/usr/bin/basename $0`
passwdID=""
login=""

if [ $# -ne 1 ] ; then
echo "Usage: /usr/local/bin/ami "
echo ' ex: /usr/local/bin/ami oracle'
exit 2
else
login=$1
fi

[ "X${RETURNMODE}" = "X" ] && RETURNMODE=0

id $login > /dev/null 2>&1
if [ $? -ne 0 ] ; then
echo "ERMS0001: Error - Invalid Login: ($login) configured in $BNAME ... Not in /etc/passwd. Terminating... "
exit 1
fi

passwdID=`grep "^${login}:" /etc/passwd | awk -F: ' { print $3 } '`

idID=`/usr/bin/id -u`

if [ "$passwdID" = "$idID" ] ; then
retval=0
else
retval=1
fi

[ $RETURNMODE -eq 1 ] && echo $retval
exit $retval