[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] SHELL=/bin/false but user can still log in
Roman Drahtmueller schrieb:
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 ;-)
Hollweg, Daniel schrieb:
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.
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
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.)
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here