[Bug 1573] ls hangs in internal-sftp

[bugzilla-daemon at bugzilla.mindrot.org]

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.