I'm most of the way there on #2. The issue is that as far as I can tell there's no way to find out the umask for a user so I don't automatically know what permissions to chmod the FCGI socket with. Now, the choices are
a) Don't chmod the FCGI socket, just chown it to the uid/gid of the user the process will run as b) Add socket_chown, socket_chmod args that only apply to unix domain sockets. This allows the most control for the user but the fact that the params don't always make sense is a bit awkward. [fcgi-program:test] command=/foo/bar.fcgi socket=unix:///tmp/test.socket socket_chown=rhoover:wheel ; this option would only apply to unix domain sockets socket_chmod=0777 ; this option would only apply to unix domain sockets user=nobody process_name=foo_%(process_num)s numprocs=2 Anyone have an opinion here? On Tue, Oct 20, 2009 at 10:57 AM, Chris McDonough <[email protected]> wrote: > Roger Hoover wrote: > >> 1) Keep the current behavior (not what people expect) - this means for >> unix domain sockets, users must set their umasks and directory permissions >> appropriately so that root can create sockets that non-root processes can >> access. >> 2) Have the root supervisord process do chmod/chown on the fcgi sockets in >> the same way it does for the chmod/chown options in the unix_http_server >> section of the config ( >> http://supervisord.org/manual/current/configuration.html#unix_http_server). >> The only question about this approach is whether it's possible to >> chown/chmod the socket so that the root supervisord process can no longer >> clean up the socket when it needs to. >> 3) Do something like Apache mod_fastcgi does with a FastCgiWrapper ( >> http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiWrapper) >> which I think means that each FCGI process group would need to fork a >> "wrapper" process that runs as the non-root user and manages the FCGI >> socket. This seems like a lot of work and potentially messy integration >> with the main supervisord event loop for dealing with SIGCHILD, etc. >> >> #2 seems the most promising. Anyone see any issues with it? I already >> tried setting chmod=0000 and chown=<non_root_user> in the unix_http_server >> section of supervisord.conf and the domain socket file was successfully >> deleted after supervisord exited. >> > > That sounds about right to me... > >
_______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
