Bug #1428
closedspawn-fcgi should not exec /bin/sh
Description
spawn-fcgi should not exec /bin/sh, it should just exec the fast-cgi server directly.
When using spawn-fcgi with the -c (chroot) parameter, it requires the chroot environment to possess /bin/sh - one of the least-desirable binaries to have in a chroot environment. It's not clear that there's any benefit of exec'ing /bin/sh -c exec <appPath> over exec'ing <appPath> directly, so why not just do that?
Files
Updated by moo about 17 years ago
/bin/sh is used to split/parse
myfcgi -b "/tmp/a b c.sock"
into pieces for execv like
myfcgi -b /tmp/a b c.sock
someone has to write code to do this job in the place of /bin/sh
Updated by bsdcat2 about 17 years ago
Related to what I suggested on the forum, wouldn't it be a reasonable interim compromise to neither parse the string nor pass it to /bin/sh for parsing? If someone wants a fastcgi server command that takes arguments, they can put it in a shell script that calls /bin/sh (or possibly, another more secure/less featureful shell), and choose to stick /bin/sh in their chroot.
A real fix would be to do the parsing internally, but this approach would still allow the user to choose to avoid /bin/sh, and also remove an undocumented dependency.
Updated by glen about 17 years ago
how about taking just argv and passing it to execvep?
if current version takes -f as argument for spawned program
leave the program and it's args as last.
spawn-fcgi -C 32 -f "/usr/bin/php.fcgi -c /etc/php/php-fcgi.ini"
would became:
spawn-fcgi -C 32 -- /usr/bin/php.fcgi -c /etc/php/php-fcgi.ini
and in case you need not to pass any args to php.fcgi:
spawn-fcgi -C 32 /usr/bin/php.fcgi
Updated by glen about 17 years ago
- Status changed from New to Fixed
- Resolution set to fixed
commited in r2023 for 1.4 and r2025 for 1.5
Updated by class101 almost 17 years ago
- Status changed from Fixed to Need Feedback
- Resolution deleted (
fixed)
Using 2026 here with spawn-fcgi in a /chroot environment and I do not see this issue patched, if I remove my /chroot/bin/sh file look at what I get:
chroot# mv bin bin2
chroot# ls
bin2 etc home lib tmp usr var
bin2# /etc/init.d/lighttpd start
Starting lighttpd: mod_proxy_core_address.c.63: (trace) adding unix:/tmp/heap.socket to the address-pool
[ OK ]
spawn-fcgi.c.233: child exited with: 2, No such file or directory
look now if I place /bin/sh in the chroot
chroot# mv bin2 bin
chroot# ls bin
sh
chroot# /etc/init.d/lighttpd start
Starting lighttpd: mod_proxy_core_address.c.63: (trace) adding unix:/tmp/heap.socket to the address-pool
[ OK ]
spawn-fcgi.c.210: child spawned successfully: PID: 23785
lighttpd 23777 0.0 0.8 44276 1168 ? Sl 17:56 0:00 /usr/local/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
2101 23785 0.0 4.1 16564 5384 ? Ss 17:56 0:00 /usr/bin/php-cgi
2101 23786 0.0 1.4 16604 1868 ? S 17:56 0:00 /usr/bin/php-cgi
2101 23787 0.0 1.4 16604 1868 ? S 17:56 0:00 /usr/bin/php-cgi
2101 23788 0.0 1.4 16604 1868 ? S 17:56 0:00 /usr/bin/php-cgi
2101 23789 0.0 1.4 16604 1868 ? S 17:56 0:00 /usr/bin/php-cgi
2101 23790 0.0 1.4 16604 1868 ? S 17:56 0:00 /usr/bin/php-cgi
doesnt look fixed to me ... using 1.50 subversion revision 2026
Updated by bsdcat2 almost 17 years ago
I don't think you read the description of how the patch changes behavior correctly.
If you wish to avoid having /bin/sh in the chroot, you must also replace '-f "and args"' with ' -- and args' at the end of the invocation of spawn-fcgi. I have tested it (patched against 1.4.18) after making that change, and I can confirm it works fine. If you made no modifications to /etc/init.d/lighttpd, it will continue to cause the old behavior and require /bin/sh in the chroot.
Updated by class101 almost 17 years ago
O right sorry apologize for the false reopening , tested with -- file at the end of the command line and was fixed , thanks for the hint :)
Updated by glen almost 17 years ago
- Status changed from Need Feedback to Fixed
- Resolution set to fixed
Also available in: Atom