admin bit super bit RedHat 下的越权执行

zmxdmdwlpz

问题：
   在没有sudo的情况下，希望不暴露root口令，得到root执行权限。
方案：
   admin bit位，就是在普通的三位之后增加一个super位，来表示可以越权执行。具体例子如下，特别说明，在脚本中要使用到的任何命令都要设置越权。
命令 chmod u+s
引用

There has always been a void in every newbies mind when it comes to sticky bits. The books say that the SUID allows an unprivileged user
to run executables and scripts with the credentials of the owner of the file. But we all try to implement it and fail as newbies. This HOWTO is dedicated to newbies of sticky bit so that they don't have to waste time in implementing it. The answer is right here.
I am taking an example of a huge organization with 1 Sysadmin who has under him/her a few Assistant Admins. In such cases, the sysadmin cannot be creating users all the time. So, the Assistant Admins do the user creation. But, to create users, the root password needs to be given to them, which is a big headache for the main Sysadmin. So, what does the sysadmin do? He/She will need to do the following :-
1. Login as root.
2. Create a shell script
that will create the users specified and set a default password for each of these users
3. Copy this script to the home directory of these assistant admins.
4. Set SUID Sticky bit to the script copied in each of the assistant admins' directories
5. Copy the sysadmin commands that will be used by your script to /bin (because most of the sysadmin commands are in the /usr/sbin directory and unprivileged users' PATH does not point to /usr/sbin)
6. Set SUID to each and every command that you copy into the bin as well (my script uses the useradd, chown and chpasswd commands)
My example shell script that creates users and sets default password for each user is as follows :-
--------------------------------------------------------------------------------------------------------------------------
echo -n "enter the starting login id : "
read beg
echo -n "enter the ending login id : "
read final
fend=`date +"%d%m%y"`
i=$beg
rm -f "users$fend"
touch "users$fend"
while [ $i -le $final ];
do
if [ $i -lt 10 ]; then
useradd "j2ee00$i"
chown -R "j2ee00$i:j2ee00$i" "/home/j2ee00$i"
echo "j2ee00$i:elmaqedu" >> "users$fend"
fi
if [ $i -ge 10 ] && [ $i -lt 100 ]; then
useradd "j2ee0$i"
chown -R "j2ee0$i:j2ee0$i" "/home/j2ee0$i"
echo "j2ee0$i:elmaqedu" >> "users$fend"
fi
if [ $i -ge 100 ] && [ $i -lt 1000 ]; then
useradd "j2ee$i"
chown -R "j2ee$i:j2ee$i" "/home/j2ee$i"
echo "j2ee$i:elmaqedu" >> "users$fend"
fi
i=$[ $i + 1 ]
done
chpasswd < "users$fend"
--------------------------------------------------------------------------------------------------------------------------
Save this script as addusers.sh
copy this script to the directories of each assistant admin. once you have copied the script, set SUID to this file using the following command :-
chmod 4755 addusers.sh
(or)
chmod u+s addusers.sh
copy the useradd and chpasswd scripts to /bin and then, issue the following commands to set the SUID to these files :-
chmod 4755 /bin/useradd
chmod 4755 /bin/chpasswd
chmod 4755 /bin/chown
THAT'S IT. IT'S ALL DONE. Now, login as any of the assistant admins and execute the addusers.sh script. The unprivileged users will be added to the /etc/passwd file
EXPLANATION
---------------------
When an unprivileged user logs into Linux, his uid and gid are embedded into his shell. From this point on, any command or script that you run forks a child shell process. Remember, every process runs with the uid and gid of the currently logged on user and hence, unprivileged users cannot write to files like /etc/passwd. Hence, SUID is actually a way in which the sysadmin can create scripts to be run by unprivileged users but still need some root like access to some system files.
once the SUID sticky bit is set on an executable created by root, the following happens :-
1. unprivileged user with uid 501 and gid 501 logs on.
2. executes a script which has SUID set.
3. Script creates a child shell process and sets it's uid and gid to 0 (the root)
4. Performs all that it needs to do and then exits
If the same unprivileged user tries to run a script without SUID set, the process will run with uid 501 and gid 501 and hence, will not have permissions to perform desired actions on system centric files, even though the sysadmin would want it to.