Hi,
I tracked down the offending line that lead to the failure of reporting
a name lookup failure in the chroot, see attached patch.
I haven't had the time to test the patch though.
The issue is already fixed in upstream's ver. 0.15.
The name lookup failure itself is due to the username being looked up
twice, once before chrooting and once after chrooting (a feature to have
CGIs unable to interfere with the main server process by using different
uids, though a little confusing). Providing a /var/www/etc/passwd with
the user is however not enough, because Debian's gatling is linked with
glibc, which uses libnss. Providing
/var/www/lib/x86_64-linux-gnu/{libnss_compat.so.2,libnsl.so.1} to the
chroot can solve this.
In a related note, I suggest to make use of start-stop-daemon's "-d"
option to give the user an option (in /etc/default/gatling) to specify
the served directory without needing to chroot into it (as a chroot does
imply some restrictions on what kind of CGI applications can be
implemented).
Yours
Thomas
--
OpenPGP Key ID: 0x6BFFE5CF3C7720398928CE741F2DAE97486A60BF
--- gatling-0.13/gatling.c.orig 2017-07-25 03:25:00.278571785 +0200
+++ gatling-0.13/gatling.c 2017-07-25 03:25:59.666866276 +0200
@@ -1382,7 +1382,7 @@
buffer fsb;
#ifndef __MINGW32__
if (chroot_to) { chdir(chroot_to); chroot(chroot_to); }
- prepare_switch_uid(new_uid);
+ if (prepare_switch_uid(new_uid)==-1) panic("switch_uid failed");
#endif
if (!io_readfile(&savedir,".")) panic("open()");
buffer_init(&fsb,(void*)read,forksock[1],fsbuf,sizeof fsbuf);
