bugzilla-daemon at bugzilla.mindrot.org
2009-Mar-16 14:51 UTC
[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.
bugzilla-daemon at bugzilla.mindrot.org
2009-Aug-12 19:09 UTC
[Bug 1573] ls hangs in internal-sftp
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.
bugzilla-daemon at bugzilla.mindrot.org
2009-Aug-13 07:58 UTC
[Bug 1573] ls hangs in internal-sftp
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.
bugzilla-daemon at bugzilla.mindrot.org
2010-Jan-14 23:58 UTC
[Bug 1573] ls hangs in internal-sftp
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.
bugzilla-daemon at bugzilla.mindrot.org
2010-Mar-25 23:51 UTC
[Bug 1573] ls hangs in internal-sftp
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.
Reasonably Related Threads
- ls hangs in internal-sftp for LDAP users
- ls hangs in internal-sftp for LDAP users
- ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names
- ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names
- internal-sftp stuck on 'ls' with chrootdirectory