openssh unix dev - May 2017 - ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names

Le 12/05/2017 ? 14:03, Alexander Wuerstlein a ?crit :
> On 2017-05-12T13:49, mh at ow2.org <mh at ow2.org> wrote:
>> Le 12/05/2017 ? 12:47, Alexander Wuerstlein a ?crit :
>>> On 2017-05-12T12:07, mh at ow2.org <mh at ow2.org> wrote:
>>>> I'm using 7.2p2-4ubuntu2.1
>>>>
>>>> I have the same exact problem as described in the first comment
in
>>>> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
>>>>
>>>> Initially, my ldap server hostname and IP is only in
/etc/hosts, not in
>>>> the configured resolver. I can't use the real IP as a
workaround in
>>>> ldap.conf because of the TLS configuration which cares about
the hostname.
>>>>
>>>> At the time I add the host name and IP in the resolver, the
issue goes away.
>>>>
>>>> So, I'm a bit worried to be forced to declare a record in
my DNS to
>>>> enable SFTP listing ? There should be another way isn't ?
>>>>
>>>> I also tried to copy /etc/hosts to etc/hosts in the folder
specified by
>>>> ChrootDirectory directive with no more success.
>>>>
>>>> Notice : it happens only for ldap users, not local users
>>>
>>> There should be a /etc/nsswitch.conf in your chroot where you can
>>> configure where users and hostnames should be looked up. E.g. to
prevent
>>> LDAP lookups altogether you could configure the respective two
lines to
>>> read:
>>> passwd:		files
>>> group:		files
>>> i.e. drop the 'ldap' option there. To check why /etc/hosts
isn't being
>>> used you can look if hosts: has 'files dns' or just
'dns' altogether
>>> behind it.
>>>
>>> But in general I would recommend putting all your hostnames into
DNS
>>> properly, in my experience this avoids all kinds of headaches with
all
>>> kinds of software. And leave /etc/hosts as empty as possible,
because
>>> that always grows inconsistent over time.
>>>
>>>
>>
>> Thanks Alexander,
>>
>> I'll try the nsswitch.conf suggestion. Until then I've noticed
the
>> following : while the ldap hostname is into the DNS, if I also put a
the
>> corresponding line to etc/hosts in the chroot the hang happens again.
So
>> the hosts file in the chroot is red somehow.
> 
> It shouldn't hang in that case, thats strange. However, the order of
the
> options in nsswitch.conf determines which way to look up the hostname is
> tried first, second, ... etc. One thing that might be a problem (but
I'm
> guessing, there might be a lot more going on[0]) would be whether you have
> just the hostname or the FQDN in your ldap.conf and /etc/hosts. And if
> its not the FQDN in some place, then what your search path in
> /etc/resolv.conf and the value of your dnsdomainname might be. 

I currently have in nsswitch.conf, in the etc folder inside the sftp's
chroot (/srv/ftpchroot/etc) :

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files

hosts:          files dns


Since I've update my DNS and switched to libnss-ldapd I can't reproduce
the hang so I'm unsure what was the cause...

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...
> 
>> But if it reads the hosts file propertly, what is the problem then ?
> 
> I'm not sure. Maybe try determining if its a ssh/sftp problem first: In
> that chroot, does 'getent passwd' hang? Does it contain only local
users
> or ldap users as well? Does 'getent hosts $ldaphostname' hang? If
yes,
> its a problem with the libc name services that are behind getent and
> stuff, so you would have to fix the config (in nsswitch.conf and all the
> related things referenced from there). strace-ing the aforementioned
> getent calls might help narrowing things further down.
I'll try to determine this if needed if I bump into the issue again.


Q: How do you mean to run getent in the sftp chroot ? you mean from the
shell ? I would need to copy a bunch of binary/lib files to achieve that
I guess.

(I'm not even sure that the files I put in /srv/ftpchroot/etc are read
in some way)

Regards,

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/

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.