Bug 4075 - uid_to_sid issues since 2.0.23 with servers under Samba NT domain
Summary: uid_to_sid issues since 2.0.23 with servers under Samba NT domain
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.23b
Hardware: All Linux
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-01 08:27 UTC by Dmitry Butskoy
Modified: 2006-11-06 13:46 UTC (History)
0 users

See Also:


Attachments
Patch which fixes this issue (963 bytes, patch)
2006-09-22 07:01 UTC, Dmitry Butskoy
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Butskoy 2006-09-01 08:27:04 UTC
I have a Samba server, which is a member of the Samba NT (+OpenLDAP + UNIX etc.) domain. Winbind is running on that server too. No any "idmap"s used, just direct "unix uid" to "samba sid" mapping at DC.

Since the upgrade to 2.0.23 some "uid==>sid" issues have appeared.

I have the option "hide unreadable = yes". With 2.0.23, some files which are actually readable appear as unreadable. The reason is Samba uses "local sid prefix" when compute SID from file's uid/gid, instead of the "domain sid prefix".


Looking at source/passdb/lookup_sid.c:uid_to_sid() :

2.0.22:

If "lp_server_role() == ROLE_DOMAIN_MEMBER", then  "winbind_uid_to_sid()" is called, and all is fine.

2.0.23:

the role check have disappeared. As a result, winbind_uid_to_sid() is not called, and pdb_uid_to_rid() is used instead. With the default passdb (smbpasswd) it knows nothing about my domain...

I have inspected the source code and it seems to be that there is no any another way to provide the previous 2.0.22 functionality. Maybe put lp_server_role() back?
Comment 1 Dmitry Butskoy 2006-09-11 11:44:36 UTC
Perhaps lp_winbind_trusted_domains_only() should be used (either instead of, or maybe accompanied with) ...
Comment 2 Dmitry Butskoy 2006-09-12 10:13:11 UTC
I've found some temporary workaround:

Specify all the uid/gid range used in the ldap/NIS system, as "idmap uid/gid" parameters for smbd/nmbd daemons, but do not change actual idmaps for winbindd.

This way, passdb/lookup_sid() will call winbind_uid_to_sid() (as all the actual uid/gid are now under idmap ranges), this request goes to winbindd daemon, winbindd calls its winbindd_uid_to_sid(), which has another idmap ranges (the actual or nothing at all), and then does the right thing according to lp_winbind_trusted_domains_only() ...

Comment 3 Dmitry Butskoy 2006-09-22 07:01:10 UTC
Created attachment 2148 [details]
Patch which fixes this issue

We can imagine that initially both uid_to_sid() always call winbind_uid_to_sid(), and then call pdb_* on unsuccess. But the call to winbind_uid_to_sid() costs the probably extra request to another process (winbindd daemon). To avoid such an extra request, the actual winbind_uid_to_sid() should be conditional -- i.e., call it only when it is useful.

To understand when it can be useful, consider the corresponding winbindd's function "winbindd_uid_to_sid()" (note two "dd", as it is winbindd's one). This function seems to be useful only when idmap is in effect, or when lp_winbind_trusted_domains_only() is on. Therefore, we should use these two conditions when initially call smbd's winbind_uid_to_sid() ...

But currently only one possible condition is checked -- whether idmap is in effect.
This patch adds "lp_winbind_trusted_domans_only()" too. 
And all the same for gid_to_sid() ...

In Samba versions prior to 2.0.23 there was an additional condition "lp_role_server() == DOMAIN_MEMBER" or something similar. It explains why it works earlier. Certainly it looked not so correctly and therefore was removed in 2.0.23. But instead of removing it should be changing to another, correct condition... :)
Comment 4 Dmitry Butskoy 2006-10-06 08:11:30 UTC
This issue also affects displaying the user/group info in the Windows's
"File Properties-->Security" window -- the domain part is showed wrong...

Strange that too low user activity on this issue... 
Really the combined domain (UNIX-NSS/OpenLDAP + Samba/OpenLDAP) is used too rarely now? Just a stand-alone or an AD slave are wide-spread?...
Comment 5 Gerald (Jerry) Carter (dead mail address) 2006-11-06 13:46:55 UTC
Dmitry, the patch looks good.  Thanks.  Applying for 3.0.23d/3.0.24