Hi,
deactivate that f$)%§)$g NSCD.
There are no side effects from nscd's operation any more (which is why it is activated by default). There used to be some oddities in SuSE Linux 6.1 and 6.2, but all of those have been resolved by now.
Better do a cat /dev/null > /etc/init.d/nscd as yast in some obscure cases automatically activates NSCD (insserv), and I never found a config Option to block this reactivation. (Often after SW-Installation. rpm-Scripts?) Maybe one of the SuSE-Guys can help with this.
An insserv -r /etc/init.d/nscd should do the trick to deactivate nscd.
Dirk Hollweg, Daniel schrieb:
Hi List,
I have an problem with my SuSe 8.2 installation with all current security patches applied. If I enter /bin/false as login shell in the /etc/passwd the user can still login and gets shell access. After rebooting the system the shell entry in the /etc/passwd is processed correct and a login attempt is closed as you would expect. Other entries like home dir in the passwd are parsed correct.
Any ideas?
It doesn't have anything to do with nscd, since nscd only caches passwd and group mappings between numerical uid and user name (gid <-> group). Even hosts caching is deactivated (I use it in the internal network without any problems.). I can't reproduce the problem right now, so it's only a guess. I could imagine that you were using telnet to log on. in.telnetd forks and execs /bin/login, which will allow multiple tries before it exits, thereby dropping the connection. The pam module that is used by login will open the passwd file once only. Since the new password file will (most likely, depending on your editor) be a new file, login will read from the old copy. If you use a new telnet connection, this effect will vanish, of course.
Thanks and regards Daniel
Thanks,
Roman.
--
- -
| Roman Drahtmüller