Is it possible to switch to root(if allowed) and then with root privileges switch to another user account "ABC"? To further explain the scenario, ABC is an account which has sugroups=su2DEF and root is not part of su2DEF group. but, given that root can switch to any account(correct me if I am wrong), is it possible for a user to switch to root and then switch to ABC? Thanks in Advance
I do not see any reason why this would not work.
su - , or su root
roots password: xxxxxxxx
You are now, to all intents and purposes, logged in as root, then:
su ABC
ABCs password: xxxxxxxx
You are now, to all intents and purposes, logged in as ABC.
Try and see!
HTH
I su to root and then su to another user all the time. Once I'm root, I am not prompted for the user's password as I su away from from root.
If your main goal is to have users switch to account ABC, then users can switch to ABC directly (without becoming root first) using:
$ su - ABC
They will be prompted for the passowrd of ABC before the sytem lets them switch to ABC.
This will prevent you from having to give the root password to ordinary users.
--Peter
Your question has already been answered by the others, but I'd like to comment on your scenario: root doesn't have to be in this group because for practial purposes root is per definition in every group there is: root can read/write any file or directory regardless of being in that particular group or not, because the normal group rights won't apply to root (to be precise: the user with UID=0).
What i want to say is: do you really need to switch away from root, given this information?
You might want to do it because the user you switch to is an application user with a very specific environment (databases often have such users) which root lacks. You also might want to do it because the process you start as this user creates some file(s) and you want these files owned by the user, not by root.
Therefore, you still might have a good reason to "su" away from root, but you might want to reestimate the need to so in light of above information.
BTW: you can su to another user for a single command with the "-c" switch. For instance:
#! /bin/ksh
# this script is started by root
/some/command_to_run_as_root
su - user1 -c /some/where/script_to_run_as_user1.sh
su - user2 -c /some/where/script_to_run_as_user2.sh
/some/other_command_to_run_as_root
exit
I hope this helps.
bakunin
Thank you all for your responses. Really appreciate it. I was asking this question from the perspective of audit. I should have given this detail before. I wanted to review the appropriateness of people who can su to ABC. Since ABC account has sugroups=su2DEF, I reviewed people who are in su2DEF group. But, given that one can su to root and then su away from root to ABC, I was wondering if I also need to look at people who can su to root. In this light I have the below questions. Unfortunately, I do not have access to the system so I can experiment. I am just doing audit review.
A) Given the above info, to determine only appropriate people can su to ABC, do I also need to look at people who can su to root?
B) Will su away from root to ABC prompt a user to enter password of ABC
C) If su away from root to ABC does not prompt the user to enter password of ABC, basically any user who can su to root can access ABC. In that case, the focus should be on people who can su to root without entering root password. How can I know which accounts have been configured to su to root without entering root password. Is there some configuration list I can review to know these accounts?
Appreciate all your advice.
Thank you
We are so relaxed here, even auditors are welcome and get answers. ;-))
I think you are looking in the wrong direction. See below.
Yes.
No.
Here it comes: in principle nobody should be allowed to become root without a password and in principle nobody is. Having said that, i will try to explain in the most non-technical fashion i can muster:
It simply makes no sense to identify people over and over again. A password is a device to identify people - "prove that you are X by entering a password only X would know". If you make someone enter the password, say, 2 times, this enhances security not one bit. Admins often have many systems to administer and usually all these systems have the same people responsible for them. As the admin switches from one system to the other he has to log on over and over again always proving to a system he is still the same as he has been the last second. This is why clever people have developed several ways to centralize this identification process and this is why it sometimes looks like an admin is able to get into a system as root without a password. This is also the reason why you might be looking not in all the necessary places. Let me explain some of the possibilities:
1) Centralized user administration
A host maintains a directory of users along with a secret to identify them (usually the password) and some credentials they have (things they are allowed to do). It is easy to conceive that it might be a good idea to centralize this information for several hosts thus creating user accounts valid for either a single host or a group of (or even all those) hosts. Basically they all work the same way: if a system should decide to let a user something do it doesn't look in its own directories of user rights but asks a centralized server for that information.
Some of these systems are: Kerberos, LDAP, DCE, NISplus, in the Windows world the pendants are Active Directory, E-Directory, X.400 and there are probably some i don't know. If your environment includes one of these systems you have to look there too and not only in the local machine.
2) sudo
To give someone the right to become root is a "everything or nothing"-decision. Either s/he is allowed to become root or not. To make this a bit more specific and adjustable there is a tool called "sudo". Basically it allows you to execute certain commands as another user (quite like "su - ... -c", see post above) but without having to enter the other users password. You enter your own password instead to identify you (or none at all). If one has to execute a certain command as root you had to give him the root password before and s/he was free to do whatever s/he wants as root, now it is possible to give him the right to execute exactly this command as root but nothing else - and don't give the root password away.
I can't explain here the complete list of possible rules which govern this process, but there is a simple check: look for a file "/etc/sudoers" and if it is there sudo is most probably used. You will have to investigate the ruleset then too.
3) ssh-keys
This is a similar idea to 1), but this time not in a centralized but a distributed way: if you connect to one system as a certain user you identify yourself. If you are allowed to connect to another system as a certain user from there it simply makes no sense to identify you again. You generate a private-/public-key pair and store the public key in a keyring on the target system after connecting to it the conventional way (with a password). From now on you don't need a password but the key pair is used to identify you.
This works only on host-user pairs and only in one direction. If you connect to host a as user a[A] and then exchange keys to connect without passwords to host b as user b [b]this doesn't mean you can connect backwards to host a as user a[A] without a password too - you would have exchange the keys in the other direction in the same manner to make that mechanism work both ways. Neither is it possble for some user c[A] on host c to connect as b [b]- this would also require to use the procedure of key exchange described above.
To find out if someone can connect to the user account using ssh keys look in the directory "~/.ssh" (default name, could be different on your system, but usually isn't) for a file "authorized_keys" (again: default name). If it exists and has entries (read it with a simple text editor) then these user/host combinations are allowed to connect to this account without password.
I hope this helps.
bakunin
Wow this is excellent information. I am amazed at how helpful people are in this forum. Thanks a ton bakunin. It greatly helps and addresses my question. Thanks to everyone who responded to my question.