Bug #1428

spawn-fcgi should not exec /bin/sh

Added by bsdcat2 almost 7 years ago. Updated over 6 years ago.

Status:FixedStart date:
Priority:HighDue date:
Assignee:-% Done:

0%

Category:spawn-fcgi
Target version:1.4.19
Missing in 1.5.x:

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?

lighttpd-spawn-fcgi-argv.patch Magnifier - accept -f <arg> as last argument, fallbacks to old -f method (2.36 KB) glen, 2007-11-10 19:26

History

#1 Updated by moo almost 7 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

#2 Updated by bsdcat2 almost 7 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.

#3 Updated by glen almost 7 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

#4 Updated by glen almost 7 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

commited in r2023 for 1.4 and r2025 for 1.5

#5 Updated by class101 almost 7 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

#6 Updated by bsdcat2 almost 7 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.

#7 Updated by class101 over 6 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 :)

#8 Updated by glen over 6 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to fixed

Also available in: Atom