Problem with nss_ldap in FreeBSD 5.3-RELEASE/AMD64

[Nathan Vidican]

Hey All,

Not entirely sure which list this should be sent to, so I figured sending to
the general list would be a good start. If there's a more appropriate list,
could someone kindly reply and direct me as to who else may be better able
to help solve or at least point me in the right direction to solve this
problem myself. - Thanks.

That said, here goes; I am apparently encountering an overflow of sorts with
nss_ldap on FreeBSD:
----------------------------------------------------------------------------
---------------------
Currently running OpenLDAP server, to store all local
usernames/passwords/groups/shells/homedirs info. The accounts are shared
between the system on the FreeBSD side using posixAccount attributes, and on
the Windows side using sambaSamAccount attributes. We are using the FreeBSD
port of LAM to create/modify/manage users and groups internally through a
web-based interface running on Apache/php. Further details, including
version specifics, etc will follow, just prefer to give you an idea of the
problem we're having before wasting your time reading all the really
specific stuff.

Here's the problem, only a few selected usernames (4 out of about 190 or
so), root cannot do a 'cd ~username'. This seems to cause issues with samba,
and the list just goes on from there. What happens when one logged in as
root types in the command 'cd ~username', is apparently an overflow of some
sort which leaves one connected to the LDAP session, a simple [CRTL]+D
releases one back to console. This same condition occurs when ANY user (not
just root) attempts to cd to one of these 4 user directories; what troubles
me most, is this happens regardless of permission issues to the filesystem,
as it is apparently during the username lookup that it happens, to what
extent the open session can allow someone access as an intruder of sorts I
do not know - but nonetheless fear as an administrator, that this could be a
security risk as well. I have attached a UNICODE txt file of a session which
shows what one gets on the console when one attempts to 'cd ~USERNAME',
where 'USERNAME' was edited removing the original username.


Here's what I've tried to resolve the issue:
--------------------------------------------
First tried re-creating the user objects in the LDAP tree, failing that, I
removed them, and re-created them with different UID numbers; essentially
making them different objects with different distinctive names (DN's) in the
database - nothing, same problem.

Removed and re-created the physical directory entries on the disk as well,
including proper ownership and permissions each time I changed the
associated entry in the LDAP tree as well - even tried changing where/which
disk the homedir was physically stored on.

Lastly, I tried removing the entire LDAP database, and restoring FIRST the
troublesome users only - same problem still. Added in the rest of the users
via an LDIF export (backup of db before I toasted it) - still same problem.
I figure spelling can't really be an issue; all usernames here follow the
same convention (first letter of first name, followed by first 7 characters
of last name, no numeric nor punctual characters of any sort). All four
usernames are phonetically distinct and do not share any alphabetic pattern
whatsoever either (I'd prefer not to send them out to the general list, as
this machine is currently in production, and given the nature of what these
accounts are causing I'd prefer not opening up a whole new security risk
here).

More Detailed Information Follows:
----------------------------------
FreeBSD 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov  5 03:50:01 UTC 2004
amd64
OpenLDAP nss_ldap & pam_ldap installed from ports-tree, using versions as
follows
  (pkg_info -a reports: openldap-client-2.2.15, openldap-server-2.2.15,
pam_ldap-1.7.1_1, nss_ldap-1.204_5)
Samba Version Samba-3.0.8, compiled with LDAP SAM support, acting as PDC for
Win2K/WinXP Clients

Still running GENERIC kernel (intent upon eventually getting around to
making a new one, removing a lot of debugging and what-not once all is up
and running well for a boost in performance).

The machine is an AMD Opteron 146-based system, with 2GB ECC registered
memory, (dual capable board, eventually going to go with dual 246 Opterons
when we can take them from a workstation and upgrade the workstation to
faster cpus). Using WDC RAID Edition S-ATA 250GB Drives, the on-board
Broadcom GigE controllers (2), and on-board ATI video controller. The drives
are configured in a RAID 5 array, attached each to an independent channel on
a 3Ware Escalade 9500 series S-ATA controller, for a total of 705GB and
change storage across 4 partitions (2GB /, 10GB /usr, 40GB /var, rest as
/server).

Attached is a copy of an (edited for username) session which details what
happens when this error occurs. There are no errors reported in the OpenLDAP
nor the system/auth logs to give you, but if anything else is needed please
don't hesitate to ask.

Any ideas as to where to go on this would be greatly appreciated, but I
genuinely think there may be something actually wrong in the code somewhere,
I don't believe this to be a simple matter of a configuration problem.

--
Nathan Vidican
nvidican at wmptl.com
Windsor Match Plate & Tool Ltd.
http://www.wmptl.com/