Personal Web Pages
From Syscore
With every user account, OIT provides the option of having a portion of your files available to the world via the WWW. Starting documentation on creating this web space is available at the OIT website. For users wishing more detailed information on the way in which these web services are provided, and other options to further customize your web environment, please read on.
Contents |
Detailed Configuration Information
UMBC runs an Apache web server, that runs under the AFS ID www.userwww. The server is configured to allow users to run CGI, php scripts, server side includes, and to also modify access via .htaccess files. The users .htaccess files are allowed to modify AuthConfig, FileInfo, and Limit configurations.
While making access restrictions with .htaccess files, it is important to note that the default ACL for the pub/www directory contains system:anyuser rl, which allows world-wide readability of ANY file in these directories via AFS, allowing users to circumvent access controls you place that are enforced by the web server. In order to limit access to directories on which you are placing web access controls, be sure to remove the system:anyuser rl entry in the respecitve directories ACLs, and replace it with www.userwww rl. Also note that if you are running CGI/php scripts out of said directories, you will have to add www.usercgi rl as well. (Please see the AFS documentation, or the manpages on the fs setacl command for further information)
The userpages web environment is very similar to the Core Web Environment, with the following important exceptions:
- PHP is ran as an external CGI, rather than a module built-in to the webserver.
- All CGI's (including php) are ran through Apache's suexec mechanism, to the user ID that holds the tokens for www.usercgi.
Access Control
Restricting Web Page Access
The Apache web server that we have as a standard here at UMBC on Unix allows for controlling access to a directory and it's subdirectories through a .htaccess file in that directory. You just need to create the proper file and an associated password file. .htaccess file
You'll want to create a file called .htaccess in the particular directory you want to be restricted. Also note that all subdirectories will be included in the restriction. The file should look similar to the following:
AuthName "Description of the login" AuthType Basic AuthUserFile /path/to/your/password/file/mentioned/below require valid-user
The AuthName is just what is displayed to the User when the username and password box pops up. The AuthType must be "Basic", this is the type that checks the password file. The AuthUserFile will be described in the next section. And the require has the options of "valid-user", "user username", or "group groupname". Password Files
In order to have a directory password protected, you must create a set of usernames and passwords that are allowed. Sometimes this is as simple as just creating one and everyone using it, or creating one for each person. To create the users, you first need to pick a file location, and then you need to find out where the program "htpasswd" is located on your system. We don't have a linux binary for this, although you could probably get one. If you are logged into an Irix machine, you can use the binary "/afs/umbc.edu/admin/www/gl/bin_irix65/htpasswd". If you just run it, it will give the syntax that it requires. Here is a basic example of creating a password file for a GL home page:
irix1[3]% cd ../pub/ irix1[4]% pwd /afs/umbc.edu/users/t/i/tim/pub irix1[5]% /usr/local/bin/htpasswd Usage: htpasswd [-c] passwordfile username The -c flag creates a new file. irix1[6]% /usr/local/bin/htpasswd -c /afs/umbc.edu/users/t/i/tim/pub/.wwwusers guest Adding password for guest. New password: Re-type new password: irix1[7]% ls -al .wwwusers -rw-r--r-- 1 tim research 20 Jan 9 16:55 .wwwusers
Just run the same command for each user, leaving off the "-c" after the first execution. This will create the password file it will use for authenticating. Also put the filename that you specified for the password in the "AuthUserFile" option in your .htaccess file. Do note that you should not put your password file under your www directory because that would mean that anyone could bring it up on the web if they knew the filename.
Further Information
Before using access control under apache, you should read [Apache's documentation on Authentication, Authorization, and Access Control]
CGI & PHP
The userpages.umbc.edu web server allows users to run standard CGI programs (via the ExecCGI mechanism) and PHP-scripted web pages. PHP-scripted pages need to end in the extension .php, and have the same usage restrictions as CGIs, so please read the CGI page mentioned above if you plan to run PHP-enhanced pages.
HowTo - A Simple Perl Script
For starters, here is a very simple perl script utilizing CGI.pm, which works in the userpages.umbc.edu environment -- and probably every other environment in the world. It takes a single user input, and does something based on that input...
#!/usr/local/bin/perl5.8.6
# Good programming practice dictates...
use strict;
# CGI.pm -- makes life easy
use CGI;
# initialize our CGI interface
my($cgi) = new CGI;
print $cgi->header();
if ( ! $cgi->param('name') ) {
print "<FORM METHOD=POST ACTION=\"".$cgi->url()."\">\n";
print "What is your name:\n";
print "<INPUT TYPE=TEXT NAME=name VALUE=\"\">\n";
print "<INPUT TYPE=SUBMIT NAME=foo VALUE=\"Go\!\">\n";
print "</FORM>\n";
} else {
print "<H1>Hello, ".$cgi->param('name')."</H1>\n";
}
HowTo - Writing To A File
Being able to write to a file in your account takes a bit more work, and requires you to set some ACL information on your account. We'll assume that you don't want the casual user to be able to view this information, so we will create a non-public directory in your 'pub' area that will be used to store the file. This directory will have the following access control list:
* system:administrators rlidwka - Standard on all directories * www.usercgi rlidwk - Allow the CGI user to read/write to this directory
(please see the below section on security -- placing these ACL entries on your directories may expose your account to potential comprimise)
And we create this directory, and set the ACL's with the following commands:
gl.umbc.edu[1]% cd ~/../pub gl.umbc.edu[2]% mkdir cgi_data gl.umbc.edu[3]% fs setacl cgi_data system:anyuser none www.usercgi write gl.umbc.edu[4]% fs listacl cgi_data Access list for cgi_data is Normal rights: system:administrators rlidwka banz rlidwka www.usercgi rlidwk
Here's a modification of the "simple example" from above that creates a DBM file in the directory we've created, and keep a count of every visitor to our page.
#!/usr/local/bin/perl5.8.6
use warnings;
use strict;
use CGI;
# initialize our CGI interface
my($cgi) = new CGI;
my(%DB);
print $cgi->header();
if ( ! $cgi->param('name') ) {
print "<FORM METHOD=POST ACTION=\"".$cgi->url()."\">\n";
print "What is your name:\n";
print "<INPUT TYPE=TEXT NAME=name VALUE=\"\">\n";
print "<INPUT TYPE=SUBMIT NAME=foo VALUE=\"Go\!\">\n";
print "</FORM>\n";
} else {
dbmopen(%DB, "/afs/umbc.edu/users/b/a/banz/pub/cgi_data/fileex", 0666)
or die "Error, cannot open database\n";
# increment the access count for this user
$DB{$cgi->param('name')}++;
print "<H1>Hello, ".$cgi->param('name')."</H1>\n";
printf "<P>You have visited this page %d time(s)!</P>", $DB{$cgi->param('name')};
dbmclose(%DB);
}
Security - There Is None
Just to be out front and 100% honest, by allowing the www.usercgi AFS user access, read or write, to files in your control, you are exposing these files to:
- Be read by others who may execute CGIs on our system, which could disclose private information stored in these files.
- Be written to by others who may execute CGIs on our system -- which could fill up your volume's quota, destroy these files, or modify the data in these files.
With that said, neither UMBC or OIT will take any responsiblity for the security or integritity of those files stored in areas that have read or write access by the www.usercgi user. In addition, we ask that any user asking for "input" on web forms that store data in these areas to make it clear that any information entered on such forms is not stored in a secure method.
PHP Restrictions
As of May, 29, 2007, the following restrictions are in place on the PHP environment:
- Upload filesize restricted to 2M
- url-based includes/opens are disabled
- register_globals & register_argc_argv are off
- Various execution functions, such as shell_exec, exec, system, suexec, escapeshellcmd, show_source, nd escapeshellarg have been disabled
Protecting Yourself
- Do not make directories which contain the CGIs themselves writable by www.usercgi. Doing so may expose you to having an unscrupulous user place an executable CGI in your account. OIT will consider any CGI located in your account as placed there by you for the purposes of our Acceptable Use Policy.
- Place "writable" areas outside of your WWW tree. Having a writable area inside of your WWW tree will make it possible for a nefarious user to place a CGI, as described above, within that directory
- Check your files regularly. If you have a "writable" area for data, check it periodically for changes to your data or extra files which you do not expect being there.
- Write Good Code. It is very easy to write CGI scripts, using the tools provided such as PHP and perl+CGI.pm, that are safe. However, it is even easier to write scripts and code that has security flaws that may allow someone, intentionally or not, to gain unauthorized access to our systems. Remember, YOU are responsible for any code that executed in your web area, and the outcomes (intended or not) of such code.
Acceptable Use
The primary purpose of the user CGI access is for instructional purposes. As mentioned in the Policy for Responsible Computing, use of UMBC systems for commercial purposes is not allowed. In addition to this restriction, we also reserve the right to remove any user CGI or Web Page that places a significant burden on resources such that the instructional mission of these services are impacted.
As mentioned above in the security section, certain assumptions are made that the users of this service will play nice, and will not use this service to:
- Write CGIs that will place a significant burden on OIT resources.
- Read, Write, Modify, Delete, or Destroy data beyond that in their own home volume.
With that said, any of the above activities will be considered, for the purposes of the previously mentioned policy as: Access information resources, data, equipment, or facilities in violation of any restriction on use, and may result in one or more of the following actions:
- Immediate revocation of CGI/Web publishing priviliges.
- Immediate revocation of access to OIT computing resources.
- Referral to the UMBC Student Judicial Board.
- ...and any other actions specified in the Policy for Responsible Computing
