# su stopped working

## lvd

After a recent update, su stopped working.

Usually I use su to change from one non-root user to another non-root one, using password for the second user. 

An hour or two ago, after usual `emerge-webrsync` and `emerge -uDU @world`, su stopped working.

auth.log now says (with correct password):

```
Feb  5 13:46:42 myserver su: FAILED SU (to lvd) rfn on pts/1
```

while previously it was (in case of wrong password):

```
Jan 30 19:12:09 myserver su[9612]: FAILED su for lvd by rfn
```

or (for correct password)

```
Jan 30 19:12:19 myserver su[9648]: Successful su for lvd by rfn
```

I see that /bin/su was really updated.

my make.conf

my /etc/pam.d/su

no special use flags for util-linux in /etc/portage/package.use

1. What happened to su?

2. How do I return my habitual function of su?

----------

## mv

 *lvd wrote:*   

> 1. What happened to su?

 

It was previously provided by sys-apps/shadow and is now provided by sys-apps/util-linux, the reason being that shadow upstream declared to no longer maintain su.

The implementation seems to be completely different. For instance, while sys-apps/shadow could be compiled with USE=-pam, the su from util-linux seems to exclusively support a pam variant.

As a temporary workaround, you can probably revert the su USE-flags for shadow and util-linux, but this is no solution in the long run.

----------

## cboldt

An alternative is to find a sudo equivalent.

The systems here do not use pam, so my alternative is to doing without su.

I don't like that, but nothing I can do about it.

----------

## pjp

I wonder how difficult it would be to create a package for su from the code that was in shadow.

----------

## Leonardo.b

su is avaiable in BusyBox and suckless utils as well.

----------

## CaptainBlood

 *Leonardo.b wrote:*   

> su is avaiable in ... suckless utils ...

 Any portage package reference?

Thks 4 ur attention, interest & support.

----------

## mv

 *cboldt wrote:*   

> An alternative is to find a sudo equivalent.
> 
> The systems here do not use pam, so my alternative is to doing without su.

 

Unfortunately, I was already forced by wayland and pipewire to use logind which does not work without pam: So I already had to byte the bullet and had to enable pam in systemd (I normally don't use it as an init system, but wayland won't work with systemd[-pam] anyway), libcap, and sddm. Now I was also forced to enable it in util-linux. My system is getting less and less secure, but having sudo as the only way to become root appears too unreliable to me. Especially since I have some root scripts which rely on su to work with less permissions (as this is the only POSIX way, though I am thinking about changing to perl or relying on zsh features for such cases).

----------

## eccerr0r

su to another user is part of POSIX regardless of pam or not, and I'd think it should be reported as a bug to util-linux if it is one.  Haven't picked up the change on my machines yet, so I guess I'll have to do this upgrade soon to do some debug ...

----------

## mv

 *eccerr0r wrote:*   

> su to another user is part of POSIX regardless of pam or not, and I'd think it should be reported as a bug to util-linux if it is one.

 

I found no comment in the upstream changelog between 2.37.2 and 2.37.3, but the ebuild contained the dependency on pam only for the latest version.

And it is not a bug in the ebuild: The configure file explicitly checks whether pam is enabled when su should be created. Due to this explicit check, it is clear that it was not an overlook by upstream, either. So I doubt that a bug report would be successful. I conjecture, they are simply too lazy to maintain a non-pam parser of passwd etc, apparently the same what happened to the shadow project.

----------

## Anon-E-moose

All that happened is that the "su" use flag was not set "+" in the shadow ebuild, but it's still there and the latest from shadow git still shows su as there.

So turn off su for util-linux and on for shadow. As for the "future" deal with any changes then

Edit to add: util-linux su does indeed need pam 

```
#include <security/pam_appl.h>
```

----------

## Leonardo.b

 *CaptainBlood wrote:*   

>  *Leonardo.b wrote:*   su is avaiable in ... suckless utils ... Any portage package reference?

 

No. Suckless.org utils conflict with coreutils/linux-utils, they are not in ::gentoo. Maybe some overlay.

The code is here: http://git.suckless.org/ubase/file/su.c.html

I am not raccomanding it, just pointing out as a possible alternative.

----------

## mv

 *Anon-E-moose wrote:*   

> All that happened is that the "su" use flag was not set "+" in the shadow ebuild, but it's still there and the latest from shadow git still shows su as there.

 

That's the technical side. The social side is that su from shadow is no longer maintained, that's why the default provider was changed.

As I said, you can (currently) easily undo the technical change, but it won't be a solution for the underlying problem but just a temporary workaround which might turn into a security issue eventually: The mere fact that su compiles and works says nothing about how secure it is (in a few months, say).

----------

## Ionen

Because of pam, shadow upstream did show some concerns after deprecating their implementation -- so whether it's really going anywhere is uncertain. There's no inherent problem with it at the moment anyhow.

On a pam-enabled system it makes little sense to not use util-linux's by default though (and Gentoo enables pam by default, so new defaults make sense, and will make things easier if shadow's version has issues or get removed at some point). Does do a few things slightly differently though, so may need adjustments depending on how you use it.

----------

## Anon-E-moose

 *mv wrote:*   

>  *Anon-E-moose wrote:*   All that happened is that the "su" use flag was not set "+" in the shadow ebuild, but it's still there and the latest from shadow git still shows su as there. 
> 
> That's the technical side. The social side is that su from shadow is no longer maintained, that's why the default provider was changed.

 

Latest -> Commits on Jan 15, 2022

I think that sometimes gentoo ebuild maintainers jump the gun on things like this. Not the first time.

Personally I don't worry about it, it's not that hard to pull the su components out of shadow. 

I got lots of things to worry about, but the security (or lack of it) for su is way down on the list. YMMV

----------

## Gatsby

 *Anon-E-moose wrote:*   

> 
> 
> I think that sometimes gentoo ebuild maintainers jump the gun on things like this. Not the first time.
> 
> Personally I don't worry about it, it's not that hard to pull the su components out of shadow. 
> ...

 

Amen.

----------

## eccerr0r

I still think util-linux should deal with not having pam installed so it's worth to tell them that not having pam is a plausible use case, and we're getting off topic here: the original post indicates the use of PAM and yet su still does not work.

----------

## mike155

 *mv wrote:*   

>  *lvd wrote:*   1. What happened to su? 
> 
> As a temporary workaround, you can probably revert the su USE-flags for shadow and util-linux, but this is no solution in the long run.

 

That's what I did. I added the lines below to /etc/portage/package.use

```
sys-apps/shadow       su

sys-apps/util-linux   -su
```

----------

## lvd

I've chrooted to a snapshot created just before the system update and can confirm that the working su there was from shadow.

Also I've taken the liberty to report su not working as a bug.

Yet, the question is how to get su from util-linux to work now.

----------

## sam_

 *eccerr0r wrote:*   

> I still think util-linux should deal with not having pam installed so it's worth to tell them that not having pam is a plausible use case, and we're getting off topic here: the original post indicates the use of PAM and yet su still does not work.

 

I did exactly that a while ago.

 *Anon-E-moose wrote:*   

>  *mv wrote:*    *Anon-E-moose wrote:*   All that happened is that the "su" use flag was not set "+" in the shadow ebuild, but it's still there and the latest from shadow git still shows su as there. 
> 
> That's the technical side. The social side is that su from shadow is no longer maintained, that's why the default provider was changed. 
> 
> Latest -> Commits on Jan 15, 2022
> ...

 

Upstream were specifically planning on removing it until we spoke to them. Gentoo generally has a philosophy

of closing following upstreams where possible.

 *cboldt wrote:*   

> An alternative is to find a sudo equivalent.
> 
> The systems here do not use pam, so my alternative is to doing without su.
> 
> I don't like that, but nothing I can do about it.

 

You can continue to use shadow's su, but the default is now util-linux's given that shadow upstream explicitly says

they prefer people to use that version.

 *lvd wrote:*   

> I've chrooted to a snapshot created just before the system update and can confirm that the working su there was from shadow.
> 
> Also I've taken the liberty to report su not working as a bug.
> 
> Yet, the question is how to get su from util-linux to work now.

 

Reported as bug 832780.

----------

## lvd

 *sam_ wrote:*   

> 
> 
> Reported as bug 832780.

 

Workaround from that bug:

 *Mike Gilbert wrote:*   

> /etc/pam.d/su has this by default:
> 
> > auth            sufficient      pam_rootok.so
> 
> > auth            required        pam_wheel.so use_uid
> ...

 

----------

## eccerr0r

Interesting, wonder if it's worth to match the behavior of shadow's su.  I think it's always standard practice that requires the user to be in the wheel group to be able to su to root, but I'm not so sure about being able to switch from one unprivileged to another unprivileged user.

----------

## szatox

Well, I think su permissions used to be controlled by chmod before pam came around. And before extended attributes.

It was executable by root and wheel, and since the binary was flagged for suid, it would always escalate permissions to root. Possibly dropping back to another user before starting shell.

----------

## dimko

sys-apps/util-linux - with suid flag

I don't know security implications.

Helped me recently with SU app.

----------

