Suexec
From Apis Networks Wiki
Contents |
Introduction
You've heard suexec mentioned in the past, right? Or some variant? If you have been around shared hosting, chances are you have heard of this mythical beast. In a nutshell,
- suexec
- a wrapper, usually a standalone binary, that processes a page request, e.g. "/index.cgi" under an environment different from the normal page requests, e.g. "/index.html" for security reasons. suexec is commonly used with CGI scripts.
suexec serves one purpose, to provide a secure environment for page requests.
Recognizing suexec-bound Pages
suexec is used to secure a dynamic page request. A dynamic page request is any page that can perform an action other than just display HTML. Dynamic pages typically have the extension .cgi, .rb, .pl, .py, .php, and so on. Those extensions, except for .php, are rendered through CGI or FastCGI (a derivative of CGI), e.g. Rails, Python, Perl, or any page that starts out with:
#!/usr/bin/<something>
This is called the shebang.
If you see that at the top of your script, it's an indication that it is a CGI script and will be bound by suexec's rules.
Static pages, that is to say pages that never change, are not bound by suexec, thus they can work so long as the world bit is read to readable. These files possess the extension .html, .gif, .jpeg, .css, .js, and so on. In other words, unless you physically replace the file, it'll come up as the same thing for every user who accesses your site.
How suexec Works
CGI Scripts as the Main User
Ok so you know suexec is used to enhance server security and you know when it's used, but one question remains: how does it operate?
This is best answered with an example.
Example 1 -- File Permissions: Let's assume we have a file called index.cgi under /var/www/html/ and your domain name is foo.com. You uploaded as the main user. We'll say that main user's username is foo. We don't care what's in the file, other than the fact it starts out with the following shebang:
#!/bin/sh
Now let's have two cases for file permissions of index.cgi:
- Case 1: The permissions of the file are 755 (owner
- rwx, group:r-x, other: r-x)
- Case 2: The permissions of the file are 644 (owner
- rw-, group:r--, other: r--)
The user opens up http://foo.com/index.cgi. Before continuing any further, only one will work. Can you guess which?
Case 1 is the correct answer. All files bound by suexec must have the permission of 755. This means any file you access directly from the Web server must have the permission of 755. Files that the CGI script opens can be anything, but as far as directly calling a dynamic page bound by suexec, it must have the permission set 755.
Example 2 -- Parent Directories: Example 1 discussed the permissions of the file, but what about the directory in which a CGI file resides? Again we will present three cases and you can choose which one is the correct answer:
- Case 1: The permissions of the directory are 700 (owner
- rwx, group:---, other:---)
- Case 2: The permissions of the directory are 757 (owner
- rwx, group:r-x, other:rwx)
- Case 3: The permissions of the directory are 755 (owner
- rwx, group:r-x, other:r-x)
As odd as it may seem, case 3 is the correct answer. The parent directory of a request must be 755. No other permission will work. Any file that the CGI script calls can be 700 though, but for the file a user accesses via his or her browser, the directory must be 755. If you're slightly confused, read on.
The Web server runs as a different user. On our servers, it runs as user apache. This user, just like your user account, has limited permissions. In order to access a directory, it needs the permissions to be in place for it to open up the directory and find the file in there, which in this case is the page request /index.cgi. This permission is handled by the other set of permission bits (75x, the x in the permission is other). In order to open up a directory, it needs the execute bit (1) set. In order to list directory contents, it needs the read bit set on the directory (4), thus 4+1 = 5 or the x in 75x.
Example 3 -- File Locations: As user foo, all CGI scripts must be under /var/www/. They can reside within any directory underneath /var/www/ such as /var/www/cgi-bin/, /var/www/html/, or even /var/www/html/x/y/z/elephants/.
Thus if you upload the CGI file as user foo, the file must be somewhere under /var/www/.
CGI Scripts as a Sub-user
Running a CGI script as a secondary user on the account follows the same permission requirements as outlined above for the main account holder, with two minor differences: (1) the CGI script must be located under ~/public_html and (2) the owner of the parent directory in which the CGI script resides (public_html/) and CGI script must be the owned by the sub-user.
