-   Linux - Security (
-   -   selinux problem with staff_u (

theillien 03-11-2012 08:31 PM

selinux problem with staff_u
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.

Anyone know what the problem could be?

T3RM1NVT0R 03-12-2012 02:16 PM

@ Reply
Hi theillien

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 -


su - root

theillien 03-12-2012 09:47 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.

elfenlied 03-12-2012 11:24 PM

I am reading the same book at the moment. In fact Michael Jang is a member of this forum and frequently responds to questions about said book (

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.

theillien 03-14-2012 10:10 PM

1 Attachment(s)
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
tells me permission denied. sudo /sbin/service iptables
tells me that iptables is an unrecognized service. I ran ls
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
attached image).

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.

elfenlied 03-14-2012 11:21 PM

1 Attachment(s)
Is the user you're running your sudo commands either in sudoers or part of the wheel group? It works when I try it, see attached.

theillien 03-15-2012 08:12 AM

1 Attachment(s)
In /etc/sudoers with the same perms as root.

All times are GMT -5. The time now is 03:43 AM.