The web server runs as its own user id, www-data. When a UNIX process runs another process, the child runs as the same user ID as the calling process. UNIX has a permissions flag on executable files called the setuid bit. If an executable is setuid, the program is run as the owner of the file, NOT as the user ID of the calling process. If a program is setuid and the owner is root, the program runs as root. Only root is able to affect the setuid bit on any file. host:~# chmod u+s program host:~# ls -l program -rwsr-xr-x 1 root root 9999 Jan 01 00:00 program* CGI is Common Gateway Interface, a standard for passing arguments and other data from the web server to other programs. It’s a protocol. It is used by the webserver to call programs run from disk, and to call interpreters built into the webserver. I use external CGI to mean the programs from disk. We use a program called suexec , which is a setuid wrapper program for external CGI. It allows a properly configured virtual hosted web site to execute CGI programs as a userid other than the one the webserver runs as. Suexec is setuid root. Anytime the webserver wants to run a CGI, it runs suexec with a parameter that indicates the path to the actual CGI program. Suexec performs a large number of tests on the CGI program to be run, making sure it is owned by the user, the directory it is in is owned by the user, it has the exact right permissions (not writable by anyone other than the owner), and many other things. Then suexec drops privileges and changes its userID to the userID of the program and runs it as that user. We require all external CGI on the server to use Suexec, which means all users that want to use CGI need a virtual host. This is because suexec is enabled by the User and Group apache config options which only work in a VirtualHost section, and cannot be specified based on Directory. ServerName username.domain.org DocumentRoot /users/username/html ScriptAlias /cgi-bin/ /var/www/htdocs/cgi-bin/username/ User username Group username TransferLog /var/log/apache/username.domain.org/access.log ErrorLog /var/log/apache/username.domain.org/error.log UserDir disabled PHP is a programming language with easy support for embedding inside HTML pages. The webserver calls a PHP interpreter which is either loaded into the webserver as a module (mod_php.so) or as an external program (command: php4). We use the mod_php loaded into the webserver for speed reasons. Any .php file on the server is interpreted by default by mod_php. Since mod_php is loaded into the apache process which runs as www-data, mod_php also runs as www-data. You can access a PostgreSQL database using PHP . To connect to the database the traditional authentication used is username and password. However, the database connection protocols are primitive and only allow plain text passwords, or identd with no password. The plain text password is not vulnerable to packet sniffers since we don’t allow remote database connections anyway. .php files in a user’s html directory are owned by that user. Since the webserver runs as www-data, the .php files need to be world-readable so the webserver, with mod_php, can read them. If you want to use a database using .php, you are going to need to store the plain text username and password in your .php file. But this needs to be world readable. So any user or any program running on the machine can obtain your database password. This problem is a result of using mod_php, which has to run as www-data. So for users who want to use database with PHP, we set them up so that requests for .php files in their website, are handled using the external program, php4, run as an external CGI. This is wrapped by suexec causing the php4 interpreter to run as the user ID owning the website. In theory you could with this setup, put your plaintext database passwords into your .php files, make the .php files readable only by your username, and it would work. But there’s a better way. Debian provides a modified version of the PostgreSQL database server with a new authentication type called peer sameuser . Using local connections between processes on the same machine, peer sameuser verifies that the UID of the database client matches the UID who owns the database being connected to. The connection is authenticated without the need for any password.
More »
Tags: