SHELL=/bin/false but user can still log in
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? Thanks and regards Daniel
Hollweg, Daniel wrote:
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.
Does the "nscd" cache also the shell field from /etc/passwd? If so, a "nscd reload" after changing the shell should prevent the user from login after that command. -- Have fun, Peter
Hi, deactivate that f$)%§)$g NSCD. 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. And then man 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?
Thanks and regards Daniel
Dirk, The cleanest way of disabling services you don't want is with the chkconfig command. Zapping /etc/init.d/nscd is a poor solution because the file may be reinstalled if you upgrade. Bob On Wed, 29 Oct 2003, Dirk Schreiner wrote:
Hi,
deactivate that f$)%§)$g NSCD.
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.
And then man 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?
Thanks and regards Daniel
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691
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
Hi Roman, Roman Drahtmueller schrieb:
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.
No side effects, OK. But that caching often makes problems too. (As this Thread shows ;-))
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.
No not in any case. Some Functionality in the yast SW-Installing-routines is able to reactivate nscd. (Never found out which exactly. ;-(() I had this Problem in several Trainings. Made a SuSE-Default installation. Told Users to deactivate NSCD (insserv -r). Installed several Network SW. And there you are, NSCD is running again. (Even on Trainer PC ;-)) (I`ll try to replay next Training, so i can tell you more.) So i made a: echo "cat /dev/null > /etc/init.d/nscd" >> boot.local and nscd is deactivated forever without telling anyone of it ;-)) Not the best way, i know. The main Problem, I think is, that nscd can not be deinstalled clean. As it`s a simple caching Daemon, it should have _no_ dependencies, although it can be part of the default installation. Neither in yast, nor in insserv. Those dependencies really need a cleanup, not only in this place. Hope 9.0/SLES9 is better at this point ;-)
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.).
This is default SuSE: # logfile /var/log/nscd.log # threads 6 # server-user nobody debug-level 0 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes and as man nscd tells us that the _database_ is chached, the whole line in /etc/passwd is cached. (With the default shell entry.) Greetings Dirk
/ 2003-10-29 07:22:53 -0000 \ Hollweg, Daniel:
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.
just a thought: "rcnscd restart" Nscd provides cacheing for the passwd(5), group(5) and hosts(5) databases through standard libc interfaces, such as getpwnam(3), getpwuid(3), getgrnam(3), getgrgid(3), gethostbyname(3) and others. Each cache has a separate TTL (time-to-live) for its data; modifying the local database ( /etc/passwd, and so forth) causes that the cache becomes invalidated within fifteen seconds. ah. maybe this ttl was not 15s but longer on your box? Note that the shadow file is specifically not cached. getspnam(3) calls remain uncached as a result. only if nscd is used by login and companions, which I assume, but did not verify. Lars Ellenberg
participants (6)
-
Bob Vickers -
Dirk Schreiner -
Hollweg, Daniel -
Lars Ellenberg -
Peter Wiersig -
Roman Drahtmueller