[Nov 23, 2009 14:09] Web access to Microsoft Live@edu accounts now works.
For CGI applications to upload (write) files to site folder(s), the file and/or directory access permissions almost always need to be set open enough for the application to do its work. Unfortunately, this also allows any user with access to the Web server to read and/or modify files. Web site vandals take advantage of this exploit to modify both the user's own Web site and other sites on the same server.
With SUCGI, the file permissions can then be set so that only the user can read and execute the file, and the SUCGI page can write in any location where the owner can write.
Note: If you are working with PHP code, you should use a specific solution tailored for PHP. Please visit our SUPHP page.
Get Started with SUCGI
- Replace the
.cgior.plfile extension with the.sucgiextension. - Make sure the file owner id matches your computing id.
- Set file permission(s) to allow read and execute access only by you (e.g.,
chmod 700 filename.sucgi).
Note: If you're using a package downloaded from the internet, you will need to analyze the files provided. Rename files
as mentioned above, and then go through all of the remaining code to replace references to
filename.cgi or filename.pl with references to
filename.sucgi .
Requirements
- The CGI file must have the
.sucgiextension. - The file must be saved in the standard Web server document areas:
/www/doc/,/www/doc_ssl/, the user's public_html directory, or sub-directories within these locations. - The reference cannot be made via a symbolic link to the file.
- The file must have owner permission to read and execute set
(e.g.,
chmod u+rx filename.sucgiorchmod 700 filename.sucgi). - The file can allow writing by the owner and the owner's group subject to limitations below.
- The directory containing the file can be writeable by the owner and the group, but not by any other users.
- The file itself and the directory it is in must have matching user and group ownership. (when access by the Web server the file will be run using the user and group ownership of the file.)
- The file must not have Unix file permissions set to force the user id or group id when run.
The user id and group id of the files and directories need to meet additional restrictions:
- The user id must be a member of the group id used.
- The user id cannot be in the list of administrative ids (those which have a numerical version of the id less than 500.)
- The group id cannot be in the list of administrative groups (those with have a numerical version of the id less than 100.
- The
idcommand on blue.unix will give you the numeric versions of your [owner] id and the numeric ids for groups to which you belong.
Managing Access Permissions and Ownership
- Permissions (read/write/execute) can be changed from the Home Directory Administrative Interface.
- User ownership can only be changed by the system administrator or by removing files and having the correct owner create them.
- Group ownership can be changed with the
chgrpcommand when logged into Unix server (blue.unix.virginia.edu for the majority of Web sites on grounds). - If your standard Unix group is usr (which is common for many users), you will need to create a new group with MyGroups. Add yourself as a member to that group.
Using SUCGI with NetBadge Authentication
If your CGI script is authenticated by NetBadge, then the user will be
required to login, but your CGI script will not recieve the user name in $REMOTE_USER. This happens
because your script is run with unauthenticated SUCGI, which is the default. To fix this problem, you must put these
lines in your .htaccess file to use NetBadge authenticated SUCGI.
Action su-cgi-script /server-cgi/netbadge/sucgi
PubcookieAppId sunetbadge
(remove any other PubcookieAppId lines)