"su " no longer works
 

I can no longer "su" into the terminal since updating to OSX Server 10.1.3 (2 domains - local and parent), I just get a "sorry" reply after entering my password.

- I do get a find with "ls su" the /usr/bin directory,
- the member from whom I'm trying to "su" is part of the group wheel -
- the root account is enabled through NetInfo
- I am logged in as the Sys Admin when attempting to "su"
- my user is part of the group "root" in NetInfo
-and I can change the root password through Netinfo, Reset password utility and can use the "sudo passwd root" command in the terminal

but I still can't "su" in

Any ideas on how to rectify or further troubleshoot I use "su" quite a lot.

can you su to any other user on your rig?

Yes I can "su" to regular users and use "sudo passwd root" to change the password - but will still not allow me to "su root"

i wonder if this has something to do with your domains. that is, if you change the root password in netinfo mgr, does it float to both domains?

i don't think "sudo passwd root" effects the changes you intend. that is, does that float back into the netinfo db?

are there any illuminating messages in console or system.log other than su: BAD SU

ok console is saying:

Mar 4 17:10:38 macserver su: BAD SU ngowr to root on /dev/ttyp1

(I have a gut feeling u may have a point re:the domains)

Sys log reiterates Console on "su" - but here is also the entry for "sudo"

Mar 4 15:50:25 macserver sudo: ngowr : TTY=ttyp1 ; PWD=/Users/ngowr ; USER=root ; COMMAND=/usr/bin/passwd root
Mar 4 15:50:41 macserver su: BAD SU ngowr to root on /dev/ttyp1

made sure both root passwords on the 2 domains where the same and enabled, rebooted and ran fsck -y.

Still no joy.

the console and system.log messages are normal.

i wish i had a sandbox machine that i could try and duplicate this situation with, but, alas, not yet.

could you show us

% id
uid=501(merv) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)

how are you changing root passwords in the two domains?

%id=

[macserver:~] ngowr% id
uid=502(ngowr) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)

The passwords for the local and parent domain are set through NetInfo through "Security" > "Change Root Password".

well, i'm stumped. any kerberos errors in the logs?

su - substitute user identity

SYNOPSIS
su [-Kflm] [login [shell arguments]]

DESCRIPTION
su requests the Kerberos password for login (or for ``login.root'', if no
login is provided), and switches to that user and group ID after obtain-
ing a Kerberos ticket granting ticket. A shell is then executed, and any
additional shell arguments after the login name are passed to the shell.
su will resort to the local password file to find the password for login
if there is a Kerberos error. If su is executed by root, no password is
requested and a shell with the appropriate user ID is executed; no addi-
tional Kerberos tickets are obtained....


any goodness in

% sudo cat /var/log/secure.log


perhaps it's time to escalate to apple? let us know.

okay here is the secure log, there was an entry 23/1 with the "authorization" file missing - however it is there now (ls command below). Are there any other logs where I can check faults on Kerberos apart from secure and system.

Jan 23 20:00:10 macserver /System/Library/CoreServices/SecurityServer: Opening rules file "/etc/authorization": No such file or directory

Mar 1 18:43:30 macserver /System/Library/CoreServices/SecurityServer: Entering service
Mar 1 18:49:48 macserver /System/Library/CoreServices/SecurityServer: Entering service
Mar 4 17:33:36 macserver /System/Library/CoreServices/SecurityServer: Entering service

[macserver:/etc] ngowr% ls -l authorization
-rw-r----- 1 root admin 3001 Oct 23 19:36 authorization

more bizarely this command "sudo su" WORKS (same password) :

Welcome to Darwin!
[macserver:~] ngowr% sudo su
Password:
[macserver:/Users/ngowr] root#

weird, i wonder if su has the special mode SUID bit set...

% ll /usr/bin/su
-r-sr-xr-x 1 root wheel 14k Dec 20 18:36 /usr/bin/su

same same

[macserver:~] ngowr% ll /usr/bin/su
-r-sr-xr-x 1 root wheel 14704 Jan 24 20:44 /usr/bin/su

do u think any of these will correct the problem:

sudo tcsh

nidump passwd . > /etc/passwd

I do have a lot of users on the server and don't want to stuff up NetInfo config.

i don't know if that will correct anything, but i would eyeball both of those, the passwd file and the nidump output.

you have users that aren't defined in the netinfo config? are you thwarting netinfo services? that's what netinfo is for, to serve many kinds of admin data needs.

Ran:
sudo tcsh >works as root

nidump passwd . > /etc/passwd

sudo update_prebinding -root /

Still can't "su root"

all users are defined in NetInfo on both domains - I don't know how else i can "thwart" NetInfo - I have amended lookupd order to read flat files before NI & DNS but obviously have run nidump passwd . > /etc/passwd. (This hasn't caused a problem on other machines with "su root".

Now my friend I am at a loss!!

o i c

well, that's thwarting. but it seems like you're on top of the dumping to the flat files. so the result is benign, i would think, unless you've found a bug.

is the password wonky with control chars? consider typing it into a text editor to see if you get what you expect.

here's an fs_usage list of interesting files that my successful su touches in it's travails. i wonder what yours looks like:

23:42:44 open /usr/lib/libSystem.B.dylib 0.000046 su
23:42:44 stat local.nidb/Config 0.000054 netinfod
23:42:44 open /dev/tty 0.000092 su
23:42:46 stat private/var/run/dev.db 0.000115 su
23:42:46 stat /dev/ttyp2 0.000030 su
23:42:46 open sr/share/zoneinfo/US/Pacific 0.000074 su

and i, suddenly, wonder, if you changed any terminal.app preferences lately. we've seen some very curious behavior in terminal if pref [ shell ] is set to
(•) use this shell, instead of (•) use default shell for this user.

are we approaching the cusp of insanity? or shall we continue hoping something shakes loose?

I modified lookupd (created it actually) in the flatfiles and this eliminated my ability to su to root. Removing the lookupd entry in the flatfiles and rebooting solved the problem.

Hugh

hugh, could you expound on that a little? i'm afraid i don't understand. thanx.