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

[Alexander Wuerstlein]

On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote:
> Le 18/05/2017 à 12:17, mh at ow2.org 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/

Yes, and additionally you want to get rid of 'compat' nsswitch entries,
because those also consult the passwd/group/... files.

Another option, if you don't want to have a socket reaching out of the
chroot (including the corresponding possible chroot escape possibility)
is to just "copy everything from ldap into a local file". Which would be
exactly what https://github.com/google/nsscache does. YMMV.



Ciao,

Alexander Wuerstlein.