Bug 429064

I've found out a configuration issue:

I had a guest account option in a share section. I know that it is usualy advertised not to use this. However it worked on my openSUSE 10.3.

I leave it up to you (developers/bug trackers) to decide what fait is to be issued upon this "bug".

Thanks.

I think we'll need a little more detail to figure out what's going on here.  Are you getting failure messages in the samba logs on startup?  Please post logs, and you might have to increase the log level to find something useful.

Ping

64 bytes from Rui Santos: icmp_seq=1 ttl=128 time=~345600 s

Sorry for the long time to reply...

Here is some more info. Here is what I attached:
- log.nmbd.bz2: nmbd daemon started with debug level 10
- log.smbd.bz2: smbd daemon started with debug level 10
- strace.nmbd.bz2: strace of a standard nmbd startup ( with no log )
- strace.smbd.bz2: strace of a standard smbd startup ( with no log )

If you need anything else please do ask.

Just to remind: This only happens when a "guest account" parameter is stated on a share section. If it is stated on the global section, then all goes well.

Thanks for your help,
Rui

Created attachment 244053 [details]
nmbd log with debug level 10

Created attachment 244054 [details]
smbd log with debug level 10

Created attachment 244055 [details]
strace of nmbd startup

Created attachment 244056 [details]
strace of smbd startup

Ralf, it looks like he's got nss_ldap issues.   From the strace...

22463 getsockname(20, {sa_family=AF_INET, sin_port=htons(45512), sin_addr=inet_addr("192.168.0.13")}, [16]) = 0
22463 getpeername(20, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.0.251")}, [68719476752]) = 0
22463 stat("/etc/ldap.conf", {st_mode=S_IFREG|0644, st_size=9809, ...}) = 0
22463 geteuid()                         = 0
22463 getsockname(20, {sa_family=AF_INET, sin_port=htons(45512), sin_addr=inet_addr("192.168.0.13")}, [85899345936]) = 0
22463 getpeername(20, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.0.251")}, [68719476752]) = 0
22463 poll([{fd=20, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = ? ERESTART_RESTARTBLOCK (To be restarted)
22463 --- SIGTERM (Terminated) @ 0 (0) ---
22463 rt_sigreturn(0xf)                 = -1 EINTR (Interrupted system call)
22463 poll([{fd=20, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = ? ERESTART_RESTARTBLOCK (To be restarted)
22463 +++ killed by SIGKILL +++

Rui,
I'm expecting that Ralf will want some nss ldap config info, like /etc/ldap.conf.  Have you verified the ldap nss setup itself?

Yes, I've checked it. Nevertheless, here is my configuration file:

base    dc=ldap,dc=grupopie,dc=com
bind_policy     soft
host    auth.grupopie.com
ldap_version    3
nss_base_group  dc=ldap,dc=grupopie,dc=com
nss_base_passwd dc=ldap,dc=grupopie,dc=com
nss_base_shadow dc=ldap,dc=grupopie,dc=com
nss_initgroups_ignoreusers      root,ldap
nss_map_attribute       uniqueMember member
nss_schema      rfc2307bis
pam_filter      objectclass=posixAccount
pam_lookup_policy       yes
pam_password    crypt
ssl     start_tls
tls_checkpeer   no

I am not able to reproduce you problem here. Please attach your non-working smb.conf file.

Created attachment 246062 [details]
Problematic smb.conf file

Here it is.

One comment regarding your configuration: AFAIK "guest account" is a global parameter, putting it into a [share] section does have no effect. It will simply be ignored.

That said, I was still unable to reproduce you problem here. Even with guest account in [global] the samba server just starts and comes up as expected. The problem must be somewhere different. Could you please attach your /etc/nsswitch.conf? And and attach the output of:

ldapsearch -x -h auth.grupopie.com -b dc=ldap,dc=grupopie,dc=com (&(objectclass=posixAccount)(uid=rsantos))

(Executed on the samba server)

Of course, here it is:

Output of provided command (just removed sambaSID):
# extended LDIF
#
# LDAPv3
# base <dc=ldap,dc=grupopie,dc=com> with scope subtree
# filter: (&(objectclass=posixAccount)(uid=rsantos))
# requesting: ALL
#

# rsantos, people, ldap.grupopie.com
dn: uid=rsantos,ou=people,dc=ldap,dc=grupopie,dc=com
cn: Rui Santos
displayName: Rui Santos
givenName: Rui
homeDirectory: /home/rsantos
loginShell: /bin/bash
mail: rsantos@grupopie.com
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: sambaSamAccount
sn: Santos
uid: rsantos
uidNumber: 1100
gidNumber: 1100
sambaSID: S-x-x-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxx-xxxx
sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
 00000000
sambaAcctFlags: [U          ]
sambaPwdLastSet: 1205246359
sambaPwdMustChange: 1205248976

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Here is the /etc/nsswitch.conf file

passwd: compat
group:  files ldap

hosts:  files mdns4_minimal [NOTFOUND=return] dns
networks:       files dns

services:       files ldap
protocols:      files
rpc:    files
ethers: files
netmasks:       files
netgroup:       files ldap
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files ldap
passwd_compat:  ldap


About your statement on the "guest account" parameter: If you read my comments 1 (one) and 4 (four), I also state that but, that same configuration worked on openSUSE 10.3. And I only get this problem when "guest account" is placed on a share section.

(In reply to comment #16 from Rui Santos)
> Here is the /etc/nsswitch.conf file
Thanks.

> About your statement on the "guest account" parameter: If you read my comments
> 1 (one) and 4 (four), I also state that but, that same configuration worked on
> openSUSE 10.3.
I read you comments. Still smbd seems to ignore the "guest account" setting in a share section. @samba-maintainers: Please correct me if I am wrong.

> And I only get this problem when "guest account" is placed on a
> share section.
Does the problem also occur if you have no "guest account" setting at all? Neither in [global] nor in [share]?

Additionally to get some more debuglogging could you please stop nscd, add "debug -1" to /etc/ldap.conf and recreate and reattach the smbd log files from comment #4. That should add some debug logging output of nss_ldap to the logs. Maybe that way we can figure out what happens.

(Re-adjusting the severity to normal for now.)

(In reply to comment #17 from Ralf Haferkamp)

> I read you comments. Still smbd seems to ignore the "guest account" setting in
> a share section. @samba-maintainers: Please correct me if I am wrong.

I believe you are right... It seems comment #1 was misleading...

> 
> > And I only get this problem when "guest account" is placed on a
> > share section.
> Does the problem also occur if you have no "guest account" setting at all?
> Neither in [global] nor in [share]?

Yes, it does. If no "guest account" parameter is defined, it defaults to "nobody", witch is NOT an ldap user. I've also tested it with that specific user:
guest account = nobody -> Samba will not start

guest account = rsantos -> Samba will start

> 
> Additionally to get some more debuglogging could you please stop nscd, add
> "debug -1" to /etc/ldap.conf and recreate and reattach the smbd log files from
> comment #4. That should add some debug logging output of nss_ldap to the logs.
> Maybe that way we can figure out what happens.

Of couse. Will attach them in a few moments... I assume you will not need the strace ones, right ? If so, please ask.
Also, with the "debug -1" option there is a lot of information send to stdout. I redirected it to a file called smbd.stdout.log

> 
> (Re-adjusting the severity to normal for now.)

Seems Ok.

> 

Created attachment 246250 [details]
nmbd log with debug level 10

Created attachment 246251 [details]
smbd log with debug level 10

Created attachment 246252 [details]
ldap log sent to stdout when started smbd

(In reply to comment #18 from Rui Santos)
[..]
> Yes, it does. If no "guest account" parameter is defined, it defaults to
> "nobody", witch is NOT an ldap user. 
Funny enough you seem to have a user "nobody" in you LDAP server. In the ldap log you attached I see that there is an entry:

uid=nobody,ou=Users,dc=ldap,dc=grupopie,dc=com

with the posixAccount attribute. You should delete that entry. It can create all sorts of confusion and errors having to users with the same name.

Additionally it seems that nss_ldap stucks shortly after reading that user. Could you please executed the following command, paste the output here and tell if it successfully returns or if it also locks up?

ldapsearch -ZZ -x -h auth.grupopie.com -b dc=ldap,dc=grupopie,dc=com
(&(objectclass=posixAccount)(uid=nobody))

It succeeds: Command outup:

# extended LDIF
#
# LDAPv3
# base <dc=ldap,dc=grupopie,dc=com> with scope subtree
# filter: (&(objectclass=posixAccount)(uid=nobody))
# requesting: ALL
#

# nobody, Users, ldap.grupopie.com
dn: uid=nobody,ou=Users,dc=ldap,dc=grupopie,dc=com
cn: nobody
sn: nobody
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
gidNumber: 514
uid: nobody
uidNumber: 999
homeDirectory: /dev/null
sambaPwdLastSet: 0
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
sambaHomePath: \\AUTH\nobody
sambaHomeDrive: H:
sambaProfilePath: \\AUTH\profiles\nobody
sambaPrimaryGroupSID: xxxx
sambaAcctFlags: [NUD        ]
sambaSID: xxxx
loginShell: /bin/false

# nobody, people, ldap.grupopie.com
dn: uid=nobody,ou=people,dc=ldap,dc=grupopie,dc=com
cn: nobody
sn: nobody
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
gidNumber: 514
uid: nobody
uidNumber: 999
homeDirectory: /dev/null
sambaPwdLastSet: 0
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
sambaHomePath: \\AUTH\nobody
sambaHomeDrive: H:
sambaProfilePath: \\AUTH\profiles\nobody
sambaPrimaryGroupSID: xxxxx
sambaAcctFlags: [NUD        ]
sambaSID: xxxxx
loginShell: /bin/false

# search result
search: 3
result: 0 Success

# numResponses: 3
# numEntries: 2

With the knowledge that you have even two "nobody" users in your LDAP database. I am able to reproduce the problem now. nss_ldap seems to hang in the getpwnam() call in that case. At least when paged_results are used (which is the default for nss_ldap).

Possible workarounds:
1. Clean up your LDAP server so that it have duplicate users anymore. As written in comment#22 having multiple users with the same name is broken and causes trouble. (You should at least remove the two "nobody" users from your LDAP server.

2. Switch off paged results in nss_ldap by adding "nss_paged_results no" to your /etc/ldap.conf until we have fixed root-cause of this problem.

The affected function is not getpwnam, but getgrouplist(). This testcase can be used to reproduce the problem (provided that there a multiple "nobody" users in LDAP):

#include <sys/types.h>
#include <grp.h>

int main (void)
{
        int ngroups=1000;
        gid_t groups[1000];
        getgrouplist("nobody", 1000, groups, &ngroups);
}

The problem is present on 11.1/SLES11 as well.

(In reply to comment #24 from Ralf Haferkamp)
> With the knowledge that you have even two "nobody" users in your LDAP database.
> I am able to reproduce the problem now. nss_ldap seems to hang in the
> getpwnam() call in that case. At least when paged_results are used (which is
> the default for nss_ldap).

Well... no comments... Those test "things" should have been deleted long ago.

> 
> Possible workarounds:
> 1. Clean up your LDAP server so that it have duplicate users anymore. As
> written in comment#22 having multiple users with the same name is broken and
> causes trouble. (You should at least remove the two "nobody" users from your
> LDAP server.

I have used solution 1 (one).

> 
> 2. Switch off paged results in nss_ldap by adding "nss_paged_results no" to
> your /etc/ldap.conf until we have fixed root-cause of this problem.
> 

Thanks for all your help. If you need any other tests... something... please do ask...

Created attachment 246829 [details]
Proposed patch for libldap

It turned out that the problem is in the OpenLDAP client libraries. The API to create the paged result controls doesn't reset libldap's internal errorcode correctly and might return the result of the previous operation instead of LDAP_SUCCESS under certain circumstances.

I'd happily test that patch.

However, since I've deleted the duplicate/triplicate users, I no longer have a capable test environment...
Do you have any suggestions ?

Fixed for 11.1Beta4.

*** Bug 444620 has been marked as a duplicate of this bug. ***