• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 [2]
Author Topic: Can't su to root (solved => chmod 4755 /bin/su)  (Read 14843 times)
samweber
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
wheel:x:107:
root@salient:/etc/pam.d# groups sweber
users
root@salient:/etc/pam.d# usermod -g wheel sweber
root@salient:/etc/pam.d# groups sweber
wheel
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
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.


Logged

plugit
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.
Logged

restamp
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.
Logged

wilhelm
Newbie
*

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.
Logged

Pages: 1 [2]
Print
Jump to: