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

[mh at ow2.org]

Le 18/05/2017 à 15:38, Alexander Wuerstlein a écrit :
> 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.
> 

Hi Alex,
Thanks,
Well, yes, but isn't it comes down exposing all the users entries to the
sftp users? (as I've mentioned above). In my case it's not that critical
but still i'm not comfortable with it in a chroot'd ftp context/usage.