Bug 1573

Summary:	ls hangs in internal-sftp
Product:	Portable OpenSSH	Reporter:	GDR! <gdr>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED FIXED
Severity:	normal	CC:	dtucker, gwikle
Priority:	P2
Version:	5.2p1
Hardware:	ix86
OS:	Linux
Bug Depends on:
Bug Blocks:	1626

Description GDR! 2009-03-17 01:51:02 AEDT

I'm using a simple configuration for chrooted sftp using openssh's internal-sftp. sshd_config here: http://gdr.pastebin.pl/6124

When I connect using sftp (or whatever else client), all commands work as desired while any variant of ls hangs.

A sample sftp session is here:
http://gdr.pastebin.pl/6125

Output of sshd -d for this session is here:
http://gdr.pastebin.pl/6126

Comment 1 gwikle 2009-08-13 05:09:55 AEST

I experienced the same problem. I used strace on the internal-sftp process and found it was trying to open /etc/hosts. Since a chroot is in effect, /etc/hosts is not found. So I put /etc/hosts into the chroot directory and saw that internal-sftp was now making queries to my LDAP authentication server. I'm guessing the queries are to look up group and user names in case it needs to report them in the ls results.

I found that if I referenced my LDAP server by IP address instead of by it's name in /etc/hosts then ls no longer hangs.

One would think that ls would have the same problem if you weren't using an external authentication server that stored group and user names. Instead of querying a server, internal-sftp would need to read /etc/passwd and /etc/groups. But in the case where there is no LDAP configured, internal-sftp simply reports the id numbers instead of the user and group names.

So why, when you are using LDAP, does internal-sftp feel it needs to report user and group names in ls output?? Seems like a bug. Also, any code path that results in a hang
is a bug (from watching the strace output I see it's not exactly hung. The process
goes to sleep for a while, wakes up to see if the server's name has been resolved,
and if not goes back to sleep. If you log in as another user while it's hung it forces
a successful LDAP query in another process which, I guess, caches the IP of the LDAP server, then the ls in the first process finally completes.)

Regardless, the workaround is to configure the authentication/LDAP server using IP address instead of using a name.

Comment 2 GDR! 2009-08-13 17:58:24 AEST

(In reply to comment #1)

I have actually edited OpenSSH source code to return user ids instead of user names and the problem mainly disappeared. 

By disappear I mean - it crawled anyway, but at least performing a ls became possible.

Comment 3 Darren Tucker 2010-01-15 10:58:36 AEDT

(In reply to comment #1)
> So why, when you are using LDAP, does internal-sftp feel it needs to
> report user and group names in ls output?? Seems like a bug.

I suspect it's because earlier the libc name functions have been initialized to know that there's an LDAP server, and continues to try to use it after the chroot.  If your libc is going to do that then you need to provide the things it needs inside its chroot.

sftp just used the system getpwuid and getgrgid, the decision to look up local files or LDAP (or NIS or ...) and how it behaves is up to the system libraries.

We've also just added a small cache for the name lookups (bug #1495) which should also help speed things up (in particular, it'll cache failures).

Comment 4 Darren Tucker 2010-03-26 10:51:13 AEDT

With the release of 5.4p1, this bug is now considered closed.