# HOWTO: make su work after installing shadow-4.0.5

## funeagle

If you install sys-apps/shadow-4.0.5 and you etc-update you might get the following error message when trying to su to root:

```
You are not authorized to su root
```

Then you have to edit /etc/login.defs and set:

```
SU_WHEEL_ONLY   no
```

----------

## nixnut

Bad idea. Better add only the users that you want to be able to su to the wheel group in /etc/group

----------

## BWoso

I am a little confused on the problem here.  In another thread one person said that they had this error while trying to su but that they were in the wheel group.  So if making being in the wheel group not a necessity how did that fix his problem (I pointed him to this post and it worked).  So he was in the wheel group, couldn't su, made being in the wheel group not needed, and it worked.  I just don't understand why that works.

----------

## gentoo4erik

Same here.

Adding to wheel group does not work

Looking at the comments in /etc/login.defs it says that you have to add your name at gid 0 (root !)

is that the right way ?

----------

## slycordinator

A better solution is to simply re-sync and update to the newest shadow version. 

sys-apps/shadow-4.0.5-r2 is the current, updated version.

----------

## gentoo4erik

I allready emerged sys-apps/shadow-4.0.5-r2

The behaviour I described, happened with shadow-4.0.5-r2

----------

## slycordinator

Strange.  I can su and I'm using shadow-4.0.5-r2

edit: But my problem with shadow-4.0.5 was having PAM authentication errors whenever trying to do usermanagement stuff.

----------

## slycordinator

It seems this bug has come back

https://bugs.gentoo.org/show_bug.cgi?id=56129

programs not setuid root

Im guessing this is the related problem.

----------

## gentoo4erik

Indeed very strange.

With sys-apps/shadow-4.0.5-r1 I had no problems. I never added myself to wheel-group and could allways use su.

Maybe relevant. Userflag = -pam

I still think the commend lines in /etc/login.defs are strange:

```
# If "yes", the user must be listed as a member of the first gid 0 group

# in /etc/group (called "root" on most Linux systems) to be able to "su"

# to uid 0 accounts.  If the group doesn't exist or is empty, no one

# will be able to "su" to uid 0.

```

nothing about wheel-group.

Groetjes,

Erik

----------

## Martin.Jansa

 *gentoo4erik wrote:*   

> Maybe relevant. Userflag = -pam

 

+pam works for me with -r2

----------

## slycordinator

 *gentoo4erik wrote:*   

> I never added myself to wheel-group and could allways use su.

 

Isn't that a considered a security risk?

----------

## TyroneSlothrop

I had the same problem since the security update of shadow.

Simple solution:

Just reemerge pam-login, shadow installed a bad (?) version of /etc/login.defs.

Strange that those packages share some files, /usr/share/man/man1/login.1.gz would be another example. Are you even supposed to have them installed at once? If yes, it smells like a bug.

----------

## Batsi

Oooh, icky.

I had that problem on my Sun today which stands a bit far away without keyboard or monitor connected.

And so I first had to organize a Sun Keyboard.  :Evil or Very Mad: 

@TyroneSlothrop: Thanks a lot. Re-emerging pam brought success.

But now I will add a few more privileges to my non-root account.   :Very Happy: 

----------

## gentoo4erik

Hoi TyroneSlothrop,

Also thanks, this helped.

Strange, that both shadow and pam-login install /etc/login.defs. But that the files differ.

Groetjes,

Erik

----------

## DeZZa

I re-emerged pam-login and it worked yesterday, but now i only get a "Sorry." message, i'm 100% sure that it is the correct password ..

[EDIT:] Changed /bin/su to 4711 from 711 ..

----------

## hielvc

Boot cd DeZZa  :Question:  Thanks you all. This thread reminded its time to back up /etc  :Laughing: 

----------

## r8dhex

ok, i was having the same problems after emerging shadow-4.0.5-r2, I re-emerged pam-login, and replaced login.defs, which fixed the "not authorized to su" problem. However, pam-login's login.defs doesn't have the line "SU_WHEEL_ONLY", so anyone can now su, which is still not the expected behavior.

It seems that SU_WHEEL_ONLY requires the wheel group to be gid 0, from what i understand from the comments. Has anyone figured out how to fix the "not authorized to su" problem, while still keeping su powers within the wheel group?

----------

## pjp

Moved from Installing Gentoo.

----------

## r8dhex

bump, since this hasn't been resolved completely yet, i think

----------

## slycordinator

The problem I'm seeing most of the people talk about is this:

Before the update they could su to root regardless of if they were in the wheel group or not, and now that they performed the update they can't.   And as far as I know, the former (su-ing regardless of group membership) is incorrect behavior for the system.

----------

## Sunny HiPPiE

 *Quote:*   

> It seems that SU_WHEEL_ONLY requires the wheel group to be gid 0, from what i understand from the comments. Has anyone figured out how to fix the "not authorized to su" problem, while still keeping su powers within the wheel group?

 

Another way is: you can list users, who can su root, in the root group, which gid by defaul is 0. It works at my machine. After the only change, that i added myuser to root group, myuser became able to su root.

----------

## ZiGZaG

finally, i got the following results:

SU_WHEEL_ONLY no in /etc/login.defs lets my user su to root

the user won't su with yes in this field, also if myuser is added to the wheel group, and the following lines commented out in login.defs seems to explain why:

```

# If "yes", the user must be listed as a member of the first gid 0 group

# in /etc/group (called "root" on most Linux systems) to be able to "su"

# to uid 0 accounts.  If the group doesn't exist or is empty, no one

# will be able to "su" to uid 0.

```

The group those lines are talking about is NOT the wheel group, but the root's one. I won't add myuser to the root group, because on my notebook i've got just one user, and the "SU_WHEEL_ONLY no" solution is acceptable for me. 

But what about my plans to make a server using gentoo at my office? 

I just can't let all users able to su to root, because both local and remote security are very important in my environment..

no changes reemerging the shadow package with or without pam in the cflags..

i still think this is a security issue of the current version of gentoo, and i wish it's going to be fixed, because it seems a BIG security problem on those systems...

NOTE: my shadow version is -r2 and all packages on my system are up to date

----------

## Malice

Bump.

Ditto here.  User is member of wheel, but can't su to root.

So to summarize what has been said so far:

Adding the user to the root group solves the problem, but this is not such a good thing for security since your user account now has psuedo-escalated privileges, and it makes the wheel group redundant.

Changing the SU_WHEEL_ONLY variable in /etc/login.defs to no also lets you su to root, but again this isn't a very desirable solution since anyone can now attempt to su to root.

The suid bit on /bin/su and other related files are set on my brandspanking new install so I don't think the bug in the shadow ebuild mentioned above is causing the problem (for me at least).

I have built everything with USE='-pam' if that makes a difference.

Ideas?

Edit:  I'm starting to get the idea that pam is pretty much a necessity to make this work properly.  This sucks, since I had conscously decided not to use pam.  Oh well, maybe I'll bite the bullet and reemerge a with pam.

----------

## hielvc

Did you check bugs.gentoo.org?

----------

## ZiGZaG

well hielvc i did.. but i didn't see a solution. is there any?   :Shocked: 

----------

## BWoso

not a solution but a way around for the time being...  Hit ctrl+alt+f11, alt+f2, log in a root, do whatever you need to do, or start emerging something or whatever. . . ctrl+alt+f7 to get back into your WM/DE

----------

## hielvc

Not offically yet. I just added my user, me, to the root group.

----------

## slycordinator

This seems to have been fixed in version  4.0.6

I have 2 new users I've put on this system.  One is my normal account, which is part of the wheel group and not part of the root group.  I added another account to test all this out which isn't in the wheel group.

Before I didn't have an entry for SU_WHEEL_ONLY in /etc/login.defs.  So at that time, anyone could su as long as they knew the password.  So I added "SU_WHEEL_ONLY  yes" to /etc/login.defs

I now can su using my normal account (the one that is in wheel) but not using the other one (the one that's not part of wheel).

btw: 4.0.6 is masked "~x86"

----------

## stealthy

I was having the same problem, although I ran into this problem because I messed up my pam...and wasn't able to log into the system cause of missing libpam_misc.so etc...and wasn't able to recompile pam-login ...it kept on failing while trying to compile login.c

so I just did:

Using LiveCD & chrooting to my system

emerge unmerge shadow pam

them emerge depclean

then added -pam to use flags

then emerge shadow

and then the system was usable once again.

although i had to recompile samba,ssh, vixie-cron etc. (whatever was using pam for authentication)

Now to the problem of not being able to su -

Still wanting to maintain unauthorised users from being able to su -, I decided to make another user, and then added that user to group root

for eg. 

username: newuser (not actual username)

primary group: users

additional groups: wheel,root,audio

did this because once the wheel issue is resolved i'll delete this new user. :Smile: 

----------

## Malice

In case anyone is wondering re-enabling pam with 

```

USE='pam' emerge -vuatD --newuse world

```

gave me back the desired behaviour - wheel members can su, but noone else can.

I had an 'oh shit' moment halfway through this build.  I had emerge running inside a detached screen, and accidentally logged out of my last shell.  When I tried to log back in again as root I got a pam error and couldn't log in.  Doh!.  Once the build had finished though I was able to log in, and everything worked as expected.

Now I know why there is a warning in the description for the pam use flag about arbitrarily flipping the value.

----------

## ZiGZaG

I did 

```

ACCEPT_KEYWORDS="~x86" emerge -u shadow

```

to do as slycordinator said, but my wheel-users still can't su to root with su_wheel_only yes

I think i'll try 

```

USE='pam' emerge -vuatD --newuse world 

```

as malice said.. when i can compile one day long of course.. because my gentoo is on a notebook   :Crying or Very sad: 

----------

## Chriske

I don't like pam, and don't want it to be installed on my system (had it before, caused a lot of conflicts, e.g. audio did not work anymore in some progs)

As far as i understand, usage of the wheel-group only works correctly using pam. But from the comment (which appears only to be present when using sys-apps shadow, without pam) in /etc/login.defs:

```
#

# If "yes", the user must be listed as a member of the first gid 0 group

# in /etc/group (called "root" on most Linux systems) to be able to "su"

# to uid 0 accounts.  If the group doesn't exist or is empty, no one

# will be able to "su" to uid 0.

#

SU_WHEEL_ONLY   yes
```

I get that shadow does not work with a wheel-group, but all users you want to be able to su, must be memeber of the root-group (with gid 0).

I tried this (adding all users who were member of the wheel-group to the root-group) and this seems to work properly (only these users can su, others can't).

Now my only question is: are ther any consequensces (e.g. security risks) when adding a user to the root-group?

----------

## gkmac

 *Chriske wrote:*   

> I don't like pam, and don't want it to be installed on my system (had it before, caused a lot of conflicts, e.g. audio did not work anymore in some progs)
> 
> As far as i understand, usage of the wheel-group only works correctly using pam.

 

I recently jettisoned PAM from my PCs and came across this SU_WHEEL_ONLY=yes issue. There something wasn't right (to me) about adding users to gid 0.

But I found a way to preserve the "wheel group" behaviour without PAM. Firstly set SU_WHEEL_ONLY=no and then create the file /etc/suauth with this single line...

```
root:ALL EXCEPT GROUP wheel:DENY
```

...and now only members of the wheel group can su to root, while everybody can su to everybody else (password permitting).

man suauth will tell you how you can apply further restrictions.

----------

## Chriske

Tnx, gkmac.

I too had problems with adding users to the root-group (that's why i posted my previous msg).

Your solution is indeed perfect, althoug i used "ALL:ALL EXCEPT GROUP wheel:DENY" to get the same effect as with PAM.

Thanks a lot.

----------

## g4c9z

By the way, what's the security risk with allowing anyone to use su?  Don't they still have to know root's password to become root?  There is a slight improvement if they can't even log in as root knowing root's password, but isn't there another way they can log in if they know root's password anyway (i.e. just log in as root in the first place)?

----------

## Chriske

The most important thing to secure your system is, of course, having a good root-password. But if you can disallow people to even try to login as root, it's even more secure.

One of these precautions is only allowing certain trusted users to su, others are disallowing root login on shh, ...

That's the way i see it.

----------

## g4c9z

OK, so otherwise, users could log in as a normal user by ssh, then su to root, even though root login is disallowed by ssh?

----------

## Chriske

Indeed, because ssh just starts bash, it does not start itsown shell. So permissions for using su are out of the control of ssh.

----------

## SCUD

Yeah, I had the exact same problem as well, compiled everything with USE=-pam" (I hate it and dont need it) and was running the latest version of shadow 4.0.5 and I couldn't su to root even though I was in the wheel group.

Based on the posts I thought I would try emerging pam-login, after that pam conveniently deleted all of my logins including root. Thanks Pam! LiveCD to the rescue...  :Rolling Eyes: 

----------

## SCUD

Just for the information of anyone out there who is interested... After I got home and booted from the LiveCD all I had to do was unmerge pam-login and shadow, then I did an:

```

emerge -pu world

```

To see exactly what packages it wanted.

I grabbed pam-login, shadow and everything else in the list then I rebooted and I could log back in. I tested out su and it works fine now.  So the latest version of shadow can work albeit with a bit of hassle (without editing any config files, allowing any security issues) and allow the correct functionality of the wheel group and su etc...

I recommend unmerging and re-emerging shadow and pam-login and hopefully that will help others.

----------

## gojensen

Hi all (my first post)

I came here because I couldn't get su to work either (fresh installed from 2005.0 updated portage as of two days ago...). I have Shadow 4.0.5-r3, and one user in the wheel group.

No matter WHAT I did the user couldn't SU. And I checked rights etc. etc. Which finally led me to this thread. For me the solution was to change /etc/login.defs, SU_WHEEL_ONLY no.

The odd thing is this; the user in the WHEEL group can now SU. If I remove the user from the WHEEL group he can NOT SU. So it seems the description here is wrong or something. I do not have PAM, and thus -PAM in the use flags.

So as of mid May 2005 this SU thing seems to not be properly resolved yet. (I do not emerge any ~x86 packages...)

----------

## afabco

It's not; it's the &(#&%(&*'ing pam thing.  System needs a +pam to do the wheel group thing.  I've tried jettisoning pam a couple of times, and all sorts of weird things happen, so I end up re-using it.  grrrrr.  I think that pam is just some of the bad baggage that we are stuck with for the foreseeable future, or until I have time to become an Uber-Uber and rewrite everything to make it an option.

----------

