Currently the SE Linux policy in rawhide has the type samba_secrets_t assigned to /etc/samba/smbpasswd and /etc/samba/secrets.tdb. This type is writable by the winbind_t domain (used for the winbind program). When the files are created by /usr/bin/smbpasswd they get the type samba_etc_t by default (which denied winbind write access to secrets.tdb). Firstly, will winbind ever need write access to /etc/samba/smbpasswd? If not then we need a separate type for it. In any case the files with types different from the other files in the directory need to be correctly labeled when they are created. If they are in a different directory then we can use the directory label to give them a default that fits our needs. If not then we need to have /usr/bin/smbpasswd modified to know about SE Linux so that it can create the files with the correct type (much like /usr/bin/passwd does when creating /etc/shadow). I'm happy to write the code for smbpasswd if that's the choice you make. But it may be easier to just use a different file location. This references bug #175922.
Internally, Samba places these in the 'private dir', so only spec file changes are required to have these files in /etc/samba/private.
Would it be ok to move private to /var/lib/samba/private ? I don;t see the need to keep binary, non-editable dbs in /etc/samba
I think the debian folks (who like to actually enforce the FHS) were wanting to do this too. The only sticking poing is the smbpasswd file itself (and upgrades) It very much depends on if smbpasswd is considered a file like other things in /etc, but the rest should be in /var/lib/samba/private.
I already do migration in FC7 for moving stuff from /var/cache/samba to /var/lib/samba so adding some more migration at this point is not a problem. I could make a local patch to keep smbpasswd in /etc/samba but admins are supposed to not edit it manually anyway and use /usr/bin/smbpasswd or pdbedit so I would not see the move as a tragedy in the next version.
btw as the original question asked for it, yes winbindd may require access to smbpasswd/passdb.tdb/ldap to check for idmap mappings in the passdb layer I am going to move everything to /var/lib/samba/private clsing this bug as rawhide, you will see a new binary soon up there, just the time to check and test an upgrade migration script to move the files.