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

Karma: 0
Posts: 61


View Profile
« on: May 07, 2009, 06:03:48 AM »

Default setup, booting from NAND.

- CAN login as root from the usb/serial terminal.

- CANNOT become root via su from a user login via usb/serial or ssh connection.  All attempts result in "Authentication failure".

Attempted to address the issue by editing /etc/pam.d/su.  Can make it worse, cannot make it better.
« Last Edit: September 01, 2009, 02:09:50 PM by samweber » Logged

iovnow
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #1 on: May 07, 2009, 06:30:18 AM »

What about 'sudo -s'?  It should give the same results.
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #2 on: May 07, 2009, 08:03:23 AM »

sudu -s, and then su -, if you want to have root's environment.
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #3 on: May 07, 2009, 11:47:00 AM »

sudo -s fails as well but with a different message:

sweber@debian:~$ sudo -s
sudo: unable to resolve host debian
[sudo] password for sweber:
sweber is not in the sudoers file.  This incident will be reported.

Note:  I had to "chmod 4755 /usr/bin/sudo" to get this far.  The first attempt to run "sudo -s" failed with a "setuid" error that I failed to capture.

The hostname bit from above will be easy to address.  Modifying the sudoers file will be less so.  I am using Procomm to get the USB/serial terminal and when I run visudo, the display goes stupid.  I've assumed that the warning in the sudoers file about hand editing is there for a reason so I haven't attempted it.  I'll have to get a terminal program under Linux working with the USB port and see if that makes it possible.  Seems odd that issue hasn't come up before since su to root is a fundamental operation.
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #4 on: May 07, 2009, 12:41:13 PM »

Seems odd that issue hasn't come up before since su to root is a fundamental operation.

Yup, you're working much too hard - there's no need for chmod'ing or any such stuff with the default root filesystem. You should be able to put your username in the sudoers file and be good to go.

Something more fundamental seems to be amiss.
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #5 on: May 07, 2009, 01:14:03 PM »

Ok.  Like what?
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #6 on: May 07, 2009, 01:33:50 PM »

Hard to tell, without knowing exactly what everything looks like.

As far as sudo goes, try something like this -- edit your sudoers file (by hand, it's OK), and make sure you have a line at the end that looks like this - at least for testing:

%sudo ALL=NOPASSWD: ALL

Then add yourself to the group like this:

usermod -a -G sudo sweber

Then at least you should be able to sudo...
Logged

plugit
Global Moderator
Full Member
*****

Karma: 0
Posts: 139



View Profile
« Reply #7 on: May 07, 2009, 01:38:45 PM »

Also, you may have more success with "putty" as your serial emulation program. Seems to do a pretty decent job.
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #8 on: May 07, 2009, 03:52:38 PM »

Thanks for all the helpful suggestions.  Here's where I got to this afternoon (I hadn't yet read the PuTTY suggestion):

The default editor invoked by visudo is nano.  Via Procomm, the text was unreadable so I couldn't edit the /etc/sudoers file.  I then did "export VISUAL=vi" and then invoked visudo (I got the idea from Mark Sobell's Ubuntu book).  That let me add the line "sweber  ALL=(ALL) ALL" to the sudoers file.  Final result:

sweber@salient:~$ su
Password:
su: Authentication failure
sweber@salient:~$ sudo -s
[sudo] password for sweber:
root@salient:~#

So direct appeals to su still result in authentication failure for some reason.  I'm extremely interested in the reason why.  I'll post here if I ever figure it out.  However, in terms of having root privileges via ssh or serial terminal, this is a big win.
Logged

JohnHughes
Newbie
*

Karma: 0
Posts: 8


View Profile
« Reply #9 on: May 08, 2009, 02:06:56 AM »

So direct appeals to su still result in authentication failure for some reason.  I'm extremely interested in the reason why.  I'll post here if I ever figure it out.  However, in terms of having root privileges via ssh or serial terminal, this is a big win.
You don't have some CR/LF conversion problem by any chance?

Have you changed the root password?
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #10 on: May 08, 2009, 06:26:37 AM »

Thats another good suggestion.  I did change the root password but I am pretty confident it works since I can login as root via usb/serial link the same way I did with the original password.
Logged

iovnow
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #11 on: May 08, 2009, 08:17:51 AM »

Yes this problem is intruiging.  What does 'su -l root' result in?
Logged

iovnow
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #12 on: May 08, 2009, 08:25:03 AM »

Also look at file /etc/pam.d/su and see if anything sticks out there.

Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #13 on: May 08, 2009, 08:50:25 AM »

sweber@salient:~$ su -l root
Password:
su: Authentication failure


Here's the contents of my /etc/pam.d/su file (this file is unmodified from the original):

sweber@salient:~$ cat /etc/pam.d/su
#
# 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

-------------------------------------------------------------------------

After reading the PAM chapter in Mark Sobell's Ubuntu book, I was absolutely convinced that the /etc/pam.d/su file was the answer.   I tried everything I could think of including the creation of a wheel group and making sweber a member of it.  No joy.  In desperation, I commented out everything in the su file but the door still never opened.  Then I thought "But wait, this is ridiculous, a stock install and I can't su?  Impossible.  The forum would be full of chatter about this".  And then I started this thread...

Logged

iovnow
Newbie
*

Karma: 0
Posts: 16


View Profile
« Reply #14 on: May 08, 2009, 01:19:32 PM »

Uncomment the following line:
# auth       sufficient pam_wheel.so trust

Add yourself to the group wheel which may need to be created if it does not exist.
Logged

Pages: [1] 2
Print
Jump to: