2

I'm have trouble launching a lighttpd fastcgi python app via upstart. I can launch the app successfully using sudo lighttpd -D -f /path/to/lighttpd.conf and via su -c "lighttpd -f /path/to/lighttpd.conf.

In upstart, I'm using the following script:

start on filesystem and started networking
stop on runlevel [06]

respawn

exec lighttpd -f /path/to/lighttpd/lighttpd.conf -D

which results in the following errors in /var/log/lighttpd/error.log:

2011-11-28 15:35:25: (mod_fastcgi.c.978) bind failed for: unix:/var/lib/lighttpd/sockets/fastcgi.python.socket-0 Permission denied 
2011-11-28 15:35:25: (mod_fastcgi.c.1399) [ERROR]: spawning fcgi failed. 
2011-11-28 15:35:25: (server.c.938) Configuration of plugins failed. Going down.

ls -l /var/lib/lighttpd/sockets/ shows

drwxr-xr-x. 2 lighttpd lighttpd 4096 Nov 28 15:19 .
drwxr-xr-x. 3 lighttpd lighttpd 4096 Nov 28 15:19 ..

and lighttpd is configured to use the lighttpd user and group (from my lighttpd.conf):

server.username  = "lighttpd"
server.groupname = "lighttpd"

I've tried adding strace in the upstart stanza but that doesn't yield anything obviously wrong. What further steps can I take to debug? What else could be causing this issue? This is on CentOS 6.

I'm starting to suspect this is selinux related. I've found this in the audit.log:

type=AVC msg=audit(1322516700.993:6418): avc:  denied  { write } for  pid=7920 comm="lighttpd" name="sockets" dev=vda3 ino=146700 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1322516701.053:6419): arch=c000003e syscall=42 success=no exit=-13 a0=5 a1=7fff848dfef0 a2=39 a3=2f7374656b636f73 items=0 ppid=1 pid=7922 auid=4294967295 uid=496 gid=490 euid=496 suid=496 fsuid=496 egid=490 sgid=490 fsgid=490 tty=(none) ses=4294967295 comm="lighttpd" exe="/usr/sbin/lighttpd" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1322516701.053:6419): avc:  denied  { write } for  pid=7922 comm="lighttpd" name="fastcgi.python.socket-0" dev=vda3 ino=146472 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:lib_t:s0 tclass=sock_file

Thanks!

bfallik-bamboom
  • 227
  • 4
  • 7

3 Answers3

1

selinux was the guilty party. Disabling selinux with echo 0>/selinux resolved the issue. I was further able to narrow the hammer to setsebool -P httpd_can_network_connect 1 but it would be nice to apply some SELinux policy change to my application instead of the system-wide.

bfallik-bamboom
  • 227
  • 4
  • 7
  • That's interesting – what else does `getsebool -a | grep httpd` show? It's weird how `httpd_can_network` is related to a socket. `getsebool` should have a bunch of cgi options too. Maybe those help? – Till Nov 29 '11 at 16:21
1

You can building custom SELinux target policies by roughly doing the following:

  • Add denied audit messages you want to allow from messages or audit log to a new file called: /etc/selinux/local/YOUR_POL.audit
  • Review the changes and if satisfied create a new selinux target:
    cat /etc/selinux/local/YOUR_POL.audit | audit2allow -m audit > YOUR_POL.te
  • Check and build module:
    checkmodule -M -m -o YOUR_POL.mod TOUR_POL.te
  • Package the module:
    semodule_package -o YOUR_POL.pp -m YOUR_POL.mod
  • Load the packaged module:
    semodule -i YOUR_POL.pp
Andrew Case
  • 3,489
  • 3
  • 23
  • 39
0
  1. I'd put the sockets in /var/run/lighttpd
  2. I'd create the sockets before-hand (touch /var/run/lighttpd/fastcgi.python.socket-0). Not sure if lighttpd gets it otherwise.
Till
  • 1,019
  • 6
  • 14
  • Can you explain why these might help? lighttpd already creates the sockets and binds to them correctly when I use sudo or su. Why would using upstart impact either the location of the sockets or their existence on disk before upstart exec's lighttpd? – bfallik-bamboom Nov 28 '11 at 21:28
  • `/var/run` is the convension for these things – `/var/lib` is for libraries. As for upstart vs. plain sudo, that is a good question. I was _assuming_ only that upstart could not write them. Did it help? Or not at all. – Till Nov 29 '11 at 16:17