"su " no longer works

[gowrann]

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.

[mervTormel]

can you su to any other user on your rig?

[gowrann]

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"

[mervTormel]

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

[gowrann]

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)

[gowrann]

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

[gowrann]

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

Still no joy.

[mervTormel]

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?

[gowrann]

%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".

[mervTormel]

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.

[gowrann]

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

[gowrann]

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

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

[mervTormel]

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

[gowrann]

same same

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

[gowrann]

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.

[mervTormel]

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.

[gowrann]

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!!

[mervTormel]

I have amended lookupd order to read flat files before NI
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?

[hschickel]

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

[mervTormel]

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

[hschickel]

merv,

Sure - I was playing around with loose end #1 in this article (http://www.macwrite.com/criticalmass/ten-mac-os-x-ends.php) from MacWrite.

Specifically, I added these flat files:

/etc/lookupd/global
LookupOrder CacheAgent FFAgent NIAgent NILAgent

and

/etc/lookupd/hosts
LookupOrder CacheAgent FFAgent NIAgent NILAgent

The file /etc/lookupd/global seemed to cause the problems. I originally tried it this way:

/etc/lookupd/global
LookupOrder CacheAgent NIAgent FFAgent NILAgent

and the system became unbootable. I switched the FFAgent and NIAgent back via single user mode and I was up and running again. But I could no longer su to root. Eliminating /etc/lookupd solved the problem. I ended up niloading this file into netinfo: {
"LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent" );
"name" = ( "lookupd" );
"MaxThreads" = ( "12" );
CHILDREN = (
{
"name" = ( "groups" );
"LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent" );
},
{
"name" = ( "users" );
"LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent" );
},
{
"name" = ( "hosts" );
"LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent", "DNSAgent", "NILAgent" );
},
{
"name" = ( "netgroups" );
"LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent" );
}
)
}


This worked without any undo effects on other logins. There are no flatfile agents mentioned in this version - although I believe there would be no problems if they were listed after NIAgent.

Hugh

[mervTormel]

thanx, hugh. i had read that article back in december, and decided i wasn't ready for any of that without further knowledge.

tho i loathe ads, and i'm still not ready for weed-whacking in netinfo, this topic and your post has been enlightening.

so, in the hierarchy of netinfo services, flat files override the netinfo db? just another level to specify where to find things? and the lowest level?

i don't want to get too off-track here, but it seems that the best laid plans... perhaps some sort of caveat is in order. is there a big red banner in the 10.1.3 release notes that says, "warning, your squirrely netinfo flat file schemes are now broken!" ? nay.

we shall wait to hear from gowrann that 10.1.3 broke his netinfo service scheme.

[gowrann]

oh.....that MacWrite article.....doh.....!!!

Yes I also did the exercise to a certain extent.... I will remove my /etc/lookupd/global file and see what happens.

[gowrann]

voila....problem fixed by removing the "global" file,
thanks for hanging in there Merv, and Hugh for the last minute goal.

Neil

[pmccann]

Congratulations all concerned, from an interested (yet distanced) bystander!

I just read the article of "interest", together with the loose ends below, and must admit that I would be a bit scared about trusting my netinfo database (or flat files) to the author without a lot more accompanying information (especially when one of the loose ends below talks about his troubles with netinfo database corruption!) There's just a little too much laissez faire within the netinfo prescriptions, and a bit of lazy fare within the loose ends: in particular, I think that some of his stuff about ssh is just plain wrong, "outlook express" does not equal "outlook", and the viral problems with Windows versions of outlook were widely known not to affect mac users. Maybe I'm just a bit grumpy because I happen to use some of these things on occasion! Defensive reflex arc...

In any case: maybe other issues of macwrite inspire greater confidence? I'll have to peck around a bit more and see. (I'm obviously not a regular reader, and am being ridiculously unfair in this message. I do quite like his jaunty writing style.)

Best Wishes,
Paul

[stetner]

Just catching up on this one....

The premis of that 'loose end' article was that the lookupd configuration in netinfo quit working at some point (10.1??).

I think that is wrong. I have my config in netinfo, use flat files for my hosts, then netinfo, then DNS and it works fine at 10.1.3 EG:% lookupd -d
lookupd version 233.1 (root 2001.11.14 22:52:19 UTC)
Enter command name, "help", or "quit" to exit
> configuration
Array: "Configuration 0" (8 objects)
[
Dictionary: "Global Configuration"
ConfigSource: netinfo://127.0.0.1/local:/locations/lookupd
DomainOrder: .
LookupOrder: CacheAgent NIAgent NILAgent
MaxIdleServers: 16
MaxIdleThreads: 16
MaxThreads: 32
TimeToLive: 43200
Timeout: 30
ValidateCache: YES
ValidationLatency: 15
_config_name: Global Configuration
name: lookupd

Dictionary: "Host Configuration"
LookupOrder: CacheAgent FFAgent NIAgent DNSAgent NILAgent
_config_name: Host Configuration
name: hosts

Dictionary: "Group Configuration"
TimeToLive: 60
ValidateCache: NO
_config_name: Group Configuration

Dictionary: "Network Configuration"
LookupOrder: CacheAgent DNSAgent NIAgent DSAgent
_config_name: Network Configuration

Dictionary: "NIAgent Configuration"
ConnectTimeout: 5
TimeToLive: 14400
Timeout: 30
ValidationLatency: 15
_config_name: NIAgent Configuration
name: NIAgent

Dictionary: "NILAgent Configuration"
TimeToLive: 3600
Timeout: 30
_config_name: NILAgent Configuration
name: NILAgent

Dictionary: "DNSAgent Configuration"
Retries: 2
Timeout: 15
_config_name: DNSAgent Configuration
name: DNSAgent

Dictionary: "CacheAgent Configuration"
TimeToLive: 14400
ValidateCache: YES
_config_name: CacheAgent Configuration
name: CacheAgent

]And the results:% lookupd -d
lookupd version 233.1 (root 2001.11.14 22:52:19 UTC)
Enter command name, "help", or "quit" to exit
> hostWithName: niprod
Dictionary: "FF: host niprod"
_lookup_FF_file: /etc/hosts
_lookup_FF_timestamp: 1015028944
_lookup_info_system: Flat_File
ip_address: 160.7.8.121
name: niprod
+ Category: host
+ Time to live: 0
+ Age: 0 (expires in 0 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 2


> hostWithName: zaqwsx
Dictionary: "NI: host zaqwsx"
_lookup_NI_checksum: 65727
_lookup_NI_index: 0
_lookup_info_system: NI
ip_address: 192.168.0.155
name: zaqwsx
+ Category: host
+ Time to live: 0
+ Age: 0 (expires in 0 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 2


> hostWithName: www.yahoo.com
Dictionary: "DNS: host www.yahoo.akadns.net"
_lookup_DNS_domain: yahoo.akadns.net
_lookup_DNS_server: 127.0.0.1
_lookup_DNS_time_to_live: 1200
_lookup_DNS_timestamp: 1015504978
_lookup_info_system: DNS
ip_address: 216.115.102.79 216.115.102.80 216.115.102.75 \
216.115.102.76 216.115.102.77 216.115.102.78
name: www.yahoo.akadns.net www.yahoo.com
+ Category: host
+ Time to live: 0
+ Age: 0 (expires in 0 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 2


> hostWithName: www.yahoo.com
Dictionary: "DNS: host www.yahoo.akadns.net"
_lookup_DNS_domain: yahoo.akadns.net
_lookup_DNS_server: 127.0.0.1
_lookup_DNS_time_to_live: 1172
_lookup_DNS_timestamp: 1015505006
_lookup_info_system: DNS
ip_address: 216.115.102.79 216.115.102.80 216.115.102.75 \
216.115.102.76 216.115.102.77 216.115.102.78
name: www.yahoo.akadns.net www.yahoo.com
+ Category: host
+ Time to live: 0
+ Age: 0 (expires in 0 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 2

> Where niprod is only in /etc/hosts, zaqwsx is only in netinfo, and www.yahoo.com is only in DNS. The only disappointment is that the CacheAgent does not seem to be used (see the second www.yahoo.com lookup, and it is the same for niprod and zaqwsx as well).

[edit: readability -mt]

[gowrann]

this is the Macwrite disclaimer:


Part 4: Troubleshooting

If you get "permission denied" errors with any of the steps, you probably aren't superuser. Type su</> at the Terminal prompt and press Enter. Give it your admin password when prompted, the same one used when you first installed OS X. If this isn't your Mac, then you are probably out of luck.

If su fails but you are certain you are an administrator, then try sudo prepended to each action command, e.g. sudo niload -v hosts / < hosts. Again, you'll need the same password as above. Earlier I showed how to create the file /etc/lookupd/global, which also inadvertently caused this problem. If it exists, try renaming that file with the command mv global global.dud, followed by a reboot.

http://www.macwrite.com/criticalmass/mac-os-x-hosts-revisited.php