openssh bugs - Mar 2009 - [Bug 1573] New: ls hangs in internal-sftp

https://bugzilla.mindrot.org/show_bug.cgi?id=1573

           Summary: ls hangs in internal-sftp
           Product: Portable OpenSSH
           Version: 5.2p1
          Platform: ix86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: gdr at go2.pl


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

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1573


gwikle at qforma.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gwikle at qforma.com




--- Comment #1 from gwikle at qforma.com  2009-08-13 05:09:55 ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1573





--- Comment #2 from GDR! <gdr at go2.pl>  2009-08-13 17:58:24 ---
(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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1573

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au
             Blocks|                            |1626
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> 2010-01-15
10:58:36 EST ---
(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).

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1573

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Darren Tucker <dtucker at zip.com.au> 2010-03-26
10:51:13 EST ---
With the release of 5.4p1, this bug is now considered closed.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.