[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] SHELL=/bin/false but user can still log in

Hi Roman,

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:

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.)


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