ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names

mh at mh at
Thu May 18 21:13:22 AEST 2017

Le 18/05/2017 à 12:17, mh at a écrit :
> However, I get uid/gid numbers instead of names within sftp session (ls
> -l) ? I don't know if it's new but I would definitively prefer names...

It seems the reason is :

open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)

okay, etc folder in the chroot wasn't world readable. If I put an entry
in the passwd file, the sftp session start resolving names.

Notice the sftp process is owned by the connecting user, and if etc/
folder is world readable, it means I expose those file to sftp user. I
don't like it but unsure if there is a better solution...

Or I could simply only resolve entries from the ldap and get rid of
passwd file (see below).

I also had this error:
socket(PF_LOCAL, SOCK_STREAM, 0)        = 4
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFD, FD_CLOEXEC|0x2)       = 0
connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) =
-1 ENOENT (No such file or directory)

Of course /var/run/nslcd/socket doesn't exist in the chroot.

To solve this I did :
mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/

More information about the openssh-unix-dev mailing list