• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 [2]
Author Topic: Can't su to root (solved => chmod 4755 /bin/su)  (Read 21230 times)
Jr. Member

Karma: 0
Posts: 61

View Profile
« Reply #15 on: May 09, 2009, 06:27:40 AM »

Thanks for another good idea.  Here's the interesting output:

Here's my edited /etc/pam.d/su file:

# The PAM configuration file for the Shadow `su' service

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

# Uncomment this to force users to be a member of group root
# before they can use `su'. You can also add "group=foo"
# to the end of this line if you want to use a group other
# than the default "root" (but this may have side effect of
# denying "root" user, unless she's a member of "foo" or explicitly
# permitted earlier by e.g. "sufficient pam_rootok.so").
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
# auth       required   pam_wheel.so

# Uncomment this if you want wheel members to be able to
# su without a password.
auth       sufficient pam_wheel.so trust

# Uncomment this if you want members of a specific group to not
# be allowed to use su at all.
# auth       required   pam_wheel.so deny group=nosu

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on su usage.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account    requisite  pam_time.so

# This module parses environment configuration file(s)
# and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# parsing /etc/environment needs "readenv=1"
session       required   pam_env.so readenv=1
# locale variables are also kept into /etc/default/locale in etch
# reading this file *in addition to /etc/environment* does not hurt
session       required   pam_env.so readenv=1 envfile=/etc/default/locale

# Defines the MAIL environment variable
# However, userdel also needs MAIL_DIR and MAIL_FILE variables
# in /etc/login.defs to make sure that removing a user
# also removes the user's mail spool file.
# See comments in /etc/login.defs
# "nopen" stands to avoid reporting new mail when su'ing to another user
session    optional   pam_mail.so nopen

# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# (Replaces the use of /etc/limits in old login)
# session    required   pam_limits.so

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session


Here's the output after the edit:

root@salient:/etc/pam.d# groupadd wheel
root@salient:/etc/pam.d# tail -1 /etc/group
root@salient:/etc/pam.d# groups sweber
root@salient:/etc/pam.d# usermod -g wheel sweber
root@salient:/etc/pam.d# groups sweber
root@salient:/etc/pam.d# cat /etc/passwd | grep sweber
sweber:x:1000:107:Sam Weber:/home/sweber:/bin/bash
root@salient:/etc/pam.d# exit
sweber@salient:~$ su
su: Authentication failure

Notice that the authorization failure now comes immediately after entering "su".  There is no password prompt in this configuration.  That must mean that authorization fails before or at the following line in the su file:

auth       sufficient pam_rootok.so

But if I understand PAM operation correctly, "sufficient" shouldn't act the same as a "required".  Sufficient means, if you pass here, you're in, but if you don't, you get to have a whack at the stanzas that follow.  Right?

When I comment out the line of interest (#auth       sufficient pam_rootok.so), the suggested line (auth       sufficient pam_wheel.so trust) becomes the first stanza.  The results in this configuration are the same.  Authorization failure upon entering "su", no password prompt.  If anything is as it seems, this behavior suggests that the authorization failure is occuring prior to the invocation of the pam.d/su file.  But what is upstream?  It also seems clear that since a login as root works and "sudo -s" works, entering "su" results in a different authentication path.  Interesting.  Frustrating, but interesting.


Global Moderator
Full Member

Karma: 0
Posts: 139

View Profile
« Reply #16 on: May 09, 2009, 07:12:49 AM »

Once again though, this is weird. The plug works fine, out of the box.

If I were you, I'd rewrite the root filesystem and start over. Seems like you're doing too much work.

Global Moderator
Sr. Member

Karma: 4
Posts: 273

View Profile
« Reply #17 on: June 15, 2009, 08:50:35 PM »

I also noticed the inability to su to root a few days ago when my SheevaPlug arrived.  A simple:

# chmod 4755 /bin/su

cured it.

Don't have any idea why they shipped it with /bin/su not privileged, but they did.


Karma: 0
Posts: 1

View Profile
« Reply #18 on: August 16, 2009, 11:46:23 AM »

It seems several of the effective user bits for root are missing.

Besides the already mentioned /bin/su permission fix (it actually tells you that it needs to have
suid root), this is also required:

chmod 4755 /usr/bin/sudo
chmod 4755 /usr/bin/passwd

If not fixed, the last one otherwise gives a "token manipulaton error" when changing the password
for oneself being a 'normal' user.

I am not familiar with PAM yet, so I can't comment on if with PAM installed one has to do a different
user setup so that these programs are run in an environment with effective userid root without
explicitly setting the suid bit - but for now, these problems I ran into are taken care of.

Pages: 1 [2]
Jump to: