Bug 4343 - ldapsam:trusted still calls getpwnam() instead of using ldap for account info
Summary: ldapsam:trusted still calls getpwnam() instead of using ldap for account info
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.23c
Hardware: Sparc Solaris
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-16 22:16 UTC by Tom Hallam
Modified: 2007-01-17 21:10 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Hallam 2007-01-16 22:16:21 UTC
According to smb.conf man page ldapsam trusted is supposed to turn off the use of getpwnam and use ldap for all account information.

"ldapsam:trusted = yes can be activated and Samba can completely bypass the NSS system to query user information. "

If a user is in ldap (all prerequisites mentioned in smb.conf are met) but removed from the local user database you get the following error log.

[2007/01/16 14:05:51, 0] passdb/pdb_get_set.c:pdb_get_group_sid(164)
  pdb_get_group_sid: Failed to find Unix account for someuser
[2007/01/16 14:05:51, 1] auth/auth_util.c:make_server_info_sam(572)
  User someuser in passdb, but getpwnam() fails!
[2007/01/16 14:05:51, 0] auth/auth_sam.c:check_sam_security(352)
  check_sam_security: make_server_info_sam() failed with 'NT_STATUS_NO_SUCH_USER'
Comment 1 Gerald (Jerry) Carter (dead mail address) 2007-01-17 06:58:21 UTC
The docs are wrong.  This option simply queries the DIT directly for 
some group information which would be very slow to obtain through NSS.
I've updated the docs.
Comment 2 Tom Hallam 2007-01-17 18:50:47 UTC
As far as I can see the docs are the only documentation of the options functional spec.  So you've just used M$ bug fix method:  Fix the bug by changing the spec.  Night is now officially day.

This is a pity as the original documented behavior would mean that samba would behave well on a server that did not have any 'local' users.  This is really handy for a virtual server without local logons. This is something REALLY NEED!

I've been looking at the code and I don't think that it'd be hard to change it so it did behave as originally documented.

I'm marking this as reopened because although the documentation is now consistent with the behavior the behavior is still not what's needed - an ability to run samba so that all user information comes from ldap without using the name services
Comment 3 Gerald (Jerry) Carter (dead mail address) 2007-01-17 21:10:30 UTC
Unless you are willing to submit a patch, don't reopen 
a bug because you disagree with me.  I was here when the 
original code was written and I am well aware of the original
intent.  I'm closing this bug report.  Please submit your
patch to samba-technical@samba.org for review once you are 
done.  Thanks.