Samba Segfault on NT Login when /etc/group contains user not in /etc/passwd or .../smbpasswd

[Alex Satrapa]

Andrew, Jeremy, Luke and co:

[this is narrative in nature... the useful bit's at the bottom]

Our Samba PDC was working fine until yesterday. Now it allows Windows
98/95 machines to log in, but when a user on an NT server tries to
login, the smbd process will either segfault, or reports "Unsupported
API fd command" (the report includes "smbd/ipc.c:api_no_reply(3198)")
(log level 3)

We haven't upgraded Samba for a while, so we figured while we're at it,
we'd get the latest Samba-NTDOM from cvs. Unfortunately, it's broken
(there are source files missing, so it won't make). We're in the process
of deleting users who've resigned, and remapping all our hosts to one
standard set of UID/GIDs.

We've done all kinds of stuff to figure out why Samba is crashing - even
succumbed to pressure from our Windows weenies to reboot our Solaris 2.6
Samba PDC. All to no avail.

There are no core dumps that I can find, and I can't type fast enough to
even think of attaching gdb to the smbd child process between the time
it's forked from the parent, and when it crashes after failing to
authenticate the user on the NT Server 4 machine.

At log level 100, I see the smbd enumerate the /etc/passwd file, then
... oh, wait a minute. That's interesting.

As smbd is looking usernames in the smbpasswd file, it gets to one that
we deleted (why?) called "uucp". However, uucp is still in one of the
groups (for zmailer, in fact). At this point, smbd tries looking for
uucp, Uucp, UUCP, uucP. Then it looks like it gives up.

Next, smbd "enumerates" (whatever that's supposed to mean in Samba
speak) a few groups from the unix<->Samba group mapping table (well,
that's the only place I can imagine it gets the group names from).

Then it segfaults.

I removed "uucp" from the "zmailer" group, and an ex-staff member from
the staff group. Now I can log in from my NT machine again.

Hmm... while I'm at it, let's copy the staff member back into a group,
but keep them out of /etc/passwd. Okay... I can still log in. There goes
that hypothesis. Hang on a moment.

Let's copy the well-known system user "uucp" back into one of our
groups, but leave it out of the /etc/passwd file. Well, what do you
know? Samba goes bye byes.

When I look at the logs after removing the staff member, smbd looks for
various capitalisations of the name ("bloggs", "Bloggs", "bloggS",
"BLOGGS"). When it can't find the staff member, it reports that the
group is now ",,,,,,,person_before_bloggs". In this case, bloggs is the
last one on the list, and person_before_bloggs is the second last. This
does not happen when the user is "uucp" instead of "bloggs".

I don't suppose you guys are doing funny stuff with "well known" system
users, are you? Is this based on user name or UID? Any chance of warning
through the log file if one of these is missing, rather than trying to
use it later on (when it doesn't exist) and segfaulting?

[didn't bother reading the narrative? Oh well... here's the summary]

It appears that smbd will segfault (why?) when a system user is present
in a /etc/group group, but not in /etc/passwd. The same is not true for
a non-system user. As a side effect of this bug, I've cleaned up our
/etc/group file, so I guess I'm a little thankful.

I can supply two trace files, for different NT hosts, on request.
They're about 1Mb each - log level 100, for a couple of login attempts
each. Don't forget to tell me if you want them ZIPed, gziped, Stuffed or
otherwise compressed.

Regards
Alex Satrapa