Solaris 8 compat mode (FIXED)
RB512C at motorola.com
Wed Aug 27 09:10:36 EDT 2003
Let me start by restating the original problem and maybe that will clear things up a bit.
By running in compat mode (passwd/nsswitch.conf), you are able to allow certain users to log into a box that is bound to a NIS domain. For example:
So what happens is login (and others) sees the "+" and knows to go look in the NIS maps for the user's password as well as the rest of their information. (In the case of the notallowed user, login(1) uses the /bin/false as the uses shell and keeps them from logging in)
What Sun changed from Solaris 2.6 to Solaris 8 (didn't use 7 so not sure how it worked..think it was the same as 2.6) was that instead of the shadow file having an empty password field.
They started putting an "x" in that field.
Now login(1) is...since the write that themselves...smart enough to know to still look for the password in the NIS maps.
Sudo, works just fine when the nsswitch.conf file is set to "files nis". But it breaks when changed to "compat" mode.
If I remove the x from the shadow file, sudo goes on and looks in the NIS file.
So I do think the problem is in sudo and how it handles password lookups in compat mode. I have tried to report a bug, but the web page keeps timing out.
From: Alek O. Komarnitsky (N-CSC) [mailto:alek at ast.lmco.com]
Sent: Tuesday, August 26, 2003 4:13 PM
To: Jason Greene; sudo-users at sudo.ws
Subject: RE: Solaris 8 compat mode (FIXED)
> From sudo-users-bounces at sudo.ws Tue Aug 26 14:20 MDT 2003
> From: Greene Jason-RB512C <RB512C at motorola.com>
> Finally got back around to looking at this problem. Thought I would post this response since I have still not see a solution posted.
> With help from Darren Dunham who pointed me to the fact that solaris 8 now puts an x in the password field of the /etc/shadow file.
> When the system is set up in compat mode (/etc/nsswitch.conf), sudo is still using the shadow file to match the password of the + users (+userid in /etc/passwd) instead of NIS.
> The solution for the moment is to take the x out of the shadow file and everything performs as it did in Solaris 2.6. But I it would seem that the sudo gods need to take a look at this and come up with a better solution for dealing with it.
> (I did test to make sure that a null password does not work when using sudo or otherwise with a blank password field in /etc/shadow)
> Thanks Again Darren!!!!!
I'm a little confused ... isn't the behavior you saw
above the desired state for things in general (also sudo).
I.e. by putting an "x" in the local shodow file, I can
lock out an account (unless you have seemless rsh or
other non-password prompt type activity) that would
otherwise be enabled via NIS.
A good test of this would be if you tried to telnet to
the machine using the setup in the "broke" example.
This requires a username/password - can you actually
using the NIS one even though the local shadow file
has an "x" listed?
More information about the sudo-users