Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm reading chapter 4 in Michael Jang's RHCSA/RHCE study guide. In the final exercise it says to set the user type for a regular user to staff_u. This type indicates that the users it applies to should have sudo and su rights. However, I seem to have encountered a problem with it.
After applying the staff_u type to a regular user, logging in as that user and then running `sudo su -` it is first telling me to enter my password, then the target user's password. Normally, I only need to enter my own as I'm not using the targetpw setting in the sudoers file.
Once it accepts my password and then the target password it takes a while to authenticate. Once it does I'm told I don't have permission to the /root/.bash_profile file so my environment is very useless. When I try to do an ls on the directory I get the same error.
Is there any specific reason you are running the following command?
sudo su -
The reason it is prompting for your password because you did a sudo and it does not appear that in /etc/sudoers you have used NOPASSWD: switch for the user account from which you are trying to run sudo.
When you are su - ing then there is no need to use sudo. You can directory do that using the following command:
su - root
Last edited by T3RM1NVT0R; 03-12-2012 at 03:17 PM.
sudo su - is force of habit. Running sudo keeps better track of who did what. It's what I do at work and it carries over to my studying.
The NOPASSWD: option does indeed eliminate the need to enter a password. However, when it is not present and I am presented with the password prompt, it is not normal behavior for it to ask for mine, and then ask for root's. It typically only asks for mine. Or, if I have targetpw set in the sudoers file, it only asks for root's. Not both.
Finally, this only became an issue when I applied the staff_u user type to my account. When I have no specific type leaving it at __default__ it works fine. That said, the problem isn't the command I'm running which is perfectly common. The problem appears to be with selinux. On the surface, anyway.
I think you might have misunderstood something in that chapter, from what I got from it was that assigning a user the staff_u context they were able to execute sudo but not su (for reasons as you've mentioned regarding logging I assume). Try it, if you do a "su -" it won't work but if you "sudo <command>" it will.
I looked into it to determine if I was just misreading it. I think I have it
right. According to table 4-8 on page 239, the staff_u role has access to the sudo command. The user_u role does not have access to the sudo or su commands (paragraph 4; same page).
I switched my account back to staff_u and logged back in. When I attempted to
run su I was told it couldn't be found. When I attempted to run sudo with another command, /usr/sbin/visudo first and then /sbin/service iptables stop second, I was unable to. sudo
/usr/sbin/visudo tells me permission denied. sudo /sbin/service iptables
stop tells me that iptables is an unrecognized service. I ran ls
/etc/init.d as a sanity check and was presented with ls: cannot access
/etc/init.d/<service>: Permission denied for every service in /etc/init.d before actually printing out the list of files (see the
I then removed the staff_u role and tried all of the same commands successfully.
I've actually talked to Mr. Jang a couple times already. I'm just hesitant to
ask him about every problem I encounter. I don't want to become a nuisance.
Especially after the last issue required a very simple fix.