2001/06/22 Will Holcomb Tennessee Tech University

will@himinbi.org

Basics of how to set up servers and clients to maintain a website using CVS.

The World Wide Web is becoming a cornerstone of having a presence on the Internet. Sites are increasingly complex and very often are maintained by a variety of people in a variety of places. The rise in popularity of the Internet has also attracted a number of unsavory characters as well; l33t haX0rs, script kiddies, industrial spies, foreign political groups and all sorts of other people who would like to alter your website for fun, profit or political expression. It is an increasing challenge for system administrators to provide the environment to their website maintainers to create a quality site and at the same time protect themselves from attackers. This document describes a system for setting up a webserver that should allow both flexibility for the maintainers and security for the administrator.

This project is developing as the setup for the webserver for the Honors Program at Tennessee Technological University. The primary webpage is maintained by the secretary using Frontpage on the campus' main IIS server. The computer committee would like to expand the presence of Honors online; particularly by doing volunteer web development for different departments on campus and for professors. Access to the IIS server is restricted to departments and faculty, so a Linux based Apache webserver is being set up to allow students to do some web development.

This server has a couple special considerations that make it a little bit different than many traditional webservers. Primarily it has to do with the maintenance patterns. Several people might be working on a page over the course of a semester and because most of the users are students, there will inevitably be several changes in maintainer over the life of a page. Also, the people collaborating on a site could have very little interaction with each other outside of their work on the pages. There are a number of priorities that need to be balanced and they are ranked as follows: Security: The server that is hosting these pages should be as resistant as possible to attack. We live in an age where websites are defaced for many reasons and it is naive to assume that our pages will be unimportant enough to warrant the attentions of a vandal. Other computers at Tech have already been attacked and defaced so there is little reason to assume that we are any safer. Accessibility: This is the most difficult issue to balance against security. Because these pages are being maintained by people who are volunteering their valuable free time it is important that it is as easy as possible for them to access the information that they need and publish their pages. Accountability: With a distributed system like this with a variety of maintainers it is important to be able to track who did what, where and when. This is important not only for the laying of blame in base of a problem, but also identifying weak points in the system. Appropriate Communication: Many of the people working on this project will never see their coworkers in the course of their daily lives. It is important for them to be able to communicate whatever information is necessary for them to work productively. It is also important though not to provide them with too much information; if the energy required to be involved is too great then it will cause people to drop out. The goal is to give them enough to keep them interested and productive but not so much as to over exert them.

The system is going to be running both a CVS repository and a webserver. The users will not update their pages directly, rather the webserver will be serving pages from a checked out copy of a CVS repository. Users will also have a home directory where they can get the kinks worked out of the site before going live. This system has several advantages: Security: Chroot: The webserver will be running inside chroot jail. This will prevent users from accessing files in the regular filesystem and will limit the exploits possible from a compromised account. Limited Login: Users will have a restricted shell and will only be allowed to perform a few basic operations like changing their passwords and running cvs. Apache: Several security constrictions will be placed on Apache to control the ways that it may be accessed and how it serves pages. SSH: Access to the repository will be via SSH. This will allow access from anywhere on the Internet with a relatively high degree of security. CVS: File permissions will be structured in such a way that users are only able to alter certain pages and they will not be able to permanently remove files from the repository. An attack could temporarily alter the pages that a user has permission to alter, but without exploiting the CVS server it is not possible to permanently alter the site. Quotas: Users will have limits on the amount of information that they can store. Disk space is not an issue and the limits will not be such that it should ever affect the ability to create a site, but it will prevent certain denial of service attacks. Accessibility: Users will be able to access their files from any platform that supports CVS. This includes nearly every operating system. WinCVS can be used for Windows users and it provides a simple GUI interface. Users will be able to edit their files in whatever editor they prefer and then upload the changed files. ViewCVS will be installed allowing users and administrators to see what changes have been made to the pages, when and by whom. Accountability: CVS will handle this in spades. The exact time, nature and owner of all changes will be recorded and reversible. Appropriate Communication: Mailman will be running on the server. There will be a variety of lists devoted to different aspects of the development. Users can subscribe or unsubscribe to lists as their needs dictate. Drawbacks: Having the whole site in CVS requires a minimum of twice the disk space of a non-CVS setup. Given the prices of hard drives however this is not a serious concern.

I am going to make these instructions as general as possible, but for reference the software that I am setting this system up on is: Redhat Linux 7.1 (www.redhat.com) with the latest updates as of 2001/08/07 OpenSSH 2.9p1 (www.openssh.org) CVS 1.11 (www.cvshome.org) Apache 1.3.19 (httpd.apache.org) Mailman 2.0.5 (www.list.org) There have been bugfixes that affect this setup. I know that I had to upgrade to this version of OpenSSH to allow a users ssh configuration files to be owned by root rather than the user. In general it is a good idea to upgrade to the latest versions of programs especially since much of the time things that are fixed are security vulnerabilities.

There are certain things that you can do to your system to make it more efficient as a webserver and also to make it more secure and resistant to attack if one of your user accounts is compromised. I will not discuss security in general which is an important part of any setup but just those that pertain to this setup. Perhaps the greatest risk in this setup is that one of your user accounts will be compromised. We will try to make it so that the worst that they can do is temporarily deface the webpage controlled by the account that was compromised. One sort of attack that you want to prevent is filling the filesystem. Running out of room can cause programs to act strangely and might allow permanent damage to files if the filesystem were filled and then files were accessed and not allowed to write completely. The simplest way to prevent these sorts of attacks is to prevent the amount of space a potential attacker is allowed to use using disk partitions and quotas.

Set up separate partitions. Files cannot spill over from one partition to another. So, it is a good idea to have /, /var, /home, /home/www and /tmp in different disk partitions. This will help isolate an attack on any particular area. Ext2 partitions you can specify mount options like noexec and nodev that will prevent programs from being executed and device files from being created respectively. If you are not deploying any cgi programs in your webpages then I highly recommend that you mount the partition noexec. You will not lose the ability to run server processed languages like php, but you will eliminate a whole realm of possible exploits on your system. Also you should consider mounting /home nosuid though for reasons I will get into later this is not possible for /home/www. Any partitions that you would like to use quotas on will also have to have the usrquota and/or grpquota mount options. These are not actually used by the mount program but other programs involved in the quota process expect for them to be present on filesystems using quotas. Partitioning will have possible additional benefits so far as disk i/o is concerned. When accessing multiple files on a single partition there are certain limits placed on how the operating system can access things because the writing of one file affects how another on the same partition can be written. If this machine is operating primarily as a webserver then this should not matter as much but it certainly shouldn't hurt anything. The setup I am using is this: Name Mount Point Minimum Size Mount Options Root / 5000mb defaults Home Directories /home 4000mb rw,nosuid,nodev HTTPD Chroot Jail /home/www 300mb rw,nosuid Web Files (Document Root and CVS Root) /home/www/files 11000mb rw,nodev,noexec,usrquota Temporary Space /tmp 2000mb rw,noexec,nodev,nosuid Temporary Program Information /var 600mb rw,noexec,nodev,nosuid

Set up quotas. This will set limits on how much different users and groups can write. Again, this is not to impose restrictions on your users so much as it is to prevent the damage that an attacker can do to the system at large from a compromised account. In order to use quotas on a particular filesystem it must have the usrquota and/or grpquota mount option. According to the mount(8) manpage these options are ignored for ext2 filesystems, but the quota management programs check for them in /etc/mtab before they will run. Before quotas can be used on a particular filesystem the accounting files have to be created using: quotacheck -c /dev/hdc2 Where /dev/hdc2 is the filesystem you want quotas on. This will create a file aquota.user at the base of the filesystem. To then edit the quota information for particular users you use: edquota username Quotas can control the amount of disk space that a user can have or the number of inodes. Both properties have both a soft and hard limit. A user is denied access if they try to write more than their hard limit, but they can write more than their soft limit. A grace period exists (edited with edquota -t) that will allow them to be over their soft limit for a certain number of days before their files are cut. Users on this system will have very limited shell access, so setting the hard limit to the same as the soft limit is will prevent any confusion.

The Apache webserver (httpd.apache.org) is by far the largest and most sophisticated program involved in out project (apart from the operating system itself.) It is fortunately also one of the most mature and it has been hardened significantly over its lifetime. There are still several things that can be done to reduce the possibility of an attacker exploiting Apache or accomplishing anything if they were to.

Chrooting. This is probably the most intensive hardening step that you can take. You will create a special directory structure to house Apache and its modules and then when it runs it will not be able to access files outside of that structure. Even if the server were somehow compromised it will not be able to access anything outside of the structure that you have created. I am not going to cover chrooting in this document because it has already been covered extensively in Securing Linux. I will briefly list the commands I issued to setup the chroot jail on my system. (Which is creating a slightly different structure than the one in Securing Linux.) ) { print "$_\n" if ($_, $_) = (/(=>) (\S+).*/); }' | sort | uniq); do cp -v $lib lib/; done cp -v /lib/libnss_dns.so.2 /lib/libnss_files.so.2 lib/ for file in localtime php.ini httpd/conf/* mime.types resolv.conf hosts; do cp -av /etc/$file etc; done for file in passwd group; do egrep ^\(apache\|root\|www\) /etc/$file > etc/$file; done mknod dev/null c 1 3 mknod dev/random c 1 8 chmod u=rwx,go=x etc dev lib modules cgi bin sbin chmod u=rwx,go= etc/ssl* var var/lock var/log var/run ]]> Something that confused me very much is that I set everything up like I thought it was supposed to be but it didn't work. Apache would die when it was starting, complaining that the "user apache didn't exist." I used ldd to get all the libraries necessary to run everything but unbeknownst to me there were other libraries being loaded. To find them I first started a chrooted shell in the environment that Apache would be running in: /usr/sbin/chroot /home/www /bin/bash Then I watched the system calls that Apache would be making using: strace /sbin/httpd Specifically I was interested in seeing files that it attempted to open that failed: &1 | grep "No such file" ]]> And from that I found that libnss_files is needed for uid to username mapping and libnss_dns is needed for host lookups. This same basic process though could be used to diagnose other problems. Once you have done any diagnostics that require a shell within the chrooted environment you can safely remove bash and the associated symlinks. This will make it more difficult for someone to start a shell in an exploit of the chrooted apache: Having created the basic file structure necessary it takes now changing the configuration files to reflect the changes. So far as Apache is concerned when it is running the root of the filesystem, /, is /home/www and everything has to be relative to that. Changes in etc/httpd.conf Changed ServerRoot to / Changed occurrences of /old.document.root/ to /files/html Changed occurrences of /var/log/httpd/ to /var/log Items that access other parts of the filesystem like "Alias /doc /usr/share/doc" cannot work in this setup. We are going to put the cvs repository inside the chroot specifically so that it can be accessed by web-based cvs browsers like cvsweb and viewcvs. Changes in /etc/sysconfig/apache (which is sourced into /etc/rc.d/init.d/httpd) Added OPTIONS="-f /etc/httpd.conf" (echo "OPTIONS=\"-f /etc/httpd.conf\"" > /etc/sysconfig/apache) Changes in /etc/rc.d/init.d/httpd Changed httpd=/usr/sbin/httpd to httpd="/usr/sbin/chroot /home/www /sbin/httpd" Changed moduledir=/usr/lib/apache to moduledir=/home/www/modules Added lock=/home/www/var/lock/httpd and replaced /var/lock/subsys/httpd with $lock Added pid=/home/www/var/run/httpd.pid and replaced /var/run/httpd.pid with $pid Changed killproc $httpd to killproc $prog (otherwise it tries to kill chroot) Changes in /etc/sysconfig/syslog (in the chroot jail Apache can no longer see /dev/log to write to syslog) Changed SYSLOGD_OPTIONS="-m 0" to SYSLOGD_OPTIONS="-m 0 -a /home/www/dev/log" Having done these things it should be possible to restart syslog with: /sbin/service syslog restart And then restart Apache using: /sbin/service httpd restart And then if it restarts properly you can test your setup with: for pid in $(/sbin/pidof httpd); do dir /proc/$pid/root; done; And instead of seeing the normal root of your filesystem you should see the chroot environment you created.

Dynamic and interactive content is the way of the future and allowing users to produce it is a good way to allow them to create more interesting and creative work. Also however it allows for a variety of security exploits since your webpages are in essence becoming programs and since your maintenance is remote it is letting people from all over run programs on your computer. There are ways to prevent the affects that these programs can have on your computer however. Chrooting is a major one, even if someone manages to get a malicious script onto your computer it will be restricted to /home/www. The main Apache process is running as root (in order to be able to bind port 80) but it does not serve content or run scripts itself, rather subprocesses are created that run as the apache user, so though root can possibly break out of a chroot jail the apache user (and thus scripts) cannot. There are two primary ways that content is generated that I am going to deal with. One is a cgi program (often written in perl, python, or C) that runs and generates content. The other is preprocessed files (like php) where the code is often intermixed with html and the file is interpreted by a server module to generate the content.

CGI programs are the most dangerous programs that you can run. They are usually written in languages that were designed to be powerful but not to be controlled. It is difficult to control the actions of cgi programs and it is a very good idea to restrict access to where they can be run from and people who can alter them as much as possible. In this setup the web root (/home/www/files/html) is on a partition that is mounted noexec so it is not possible to run cgi programs in the web root. It is a good idea to go ahead and set up Apache as though it were possible though since the mount options might change later and you would not want to be vulnerable. There are a couple of apache directives to control how cgi is run. You should place these in the primary Directory directive in etc/httpd.conf: Options SymLinksIfOwnerMatch IncludesNOEXEC AllowOverride None Order deny,allow Deny from all ]]> Then in the entry for your web root you can allow slightly more liberal access but still disallow cgi. Options +Indexes AllowOverride AuthConfig Order allow,deny Allow from all ]]> If you are going to run specific cgi programs like cvsweb, mailman, or awstats, I recommend creating a directory for them that is only accessible through an alias. For example, installing cvsweb: put the files in /home/www/cgi/cvsweb then add a directive to etc/httpd.conf like: AllowOverride None Options ExecCGI Order allow,deny Allow from all ]]>

Another method of generating content is server parsed files. These are languages that are written knowing that they will be executed on webservers and so many times considerations were made to allow tightened security. The most popular server parsed language for Apache is php and there are certain changes that you can make to etc/php.ini to restrict what php can do. Set "open_basedir = /files/html" or "open_basedir = .". Files may not be opened from outside of the specified directory structure. For instance an attacker couldn't open("/etc/passwd") and print the entries in a webpage. The special value of . will limit access to within or below the directory housing the script. Set "memory_limit = 204800". This will limit a script to 200K (1024 * 200) of memory. This could prevent a denial of service if someone put a script on the server that used lots of memory and then accessed it very quickly. Set "max_execution_time = 30". This is the default value for this entry and it is a reasonable value. Used in conjunction with memory_limit this controls the detriment that malicious (or poorly written) scripts can have on the server. Set "safe_mode = on". This enables several security restrictions. When opening files the owner of the script must be the same as the owner of the file. (Using the CVS setup that we are doing all files will be owned by apache so this is mute.) Connections to a MySQL database must be made using the same username as the owner of the file. The user id is prepended to the HTTP authentication realm (this "prevents someone from writing a password.") Set "doc_root = /files/html". Enabled by "safe_mode = on", this will prevent php from serving any files from outside of that directory structure. Set "safe_mode_exec_dir = /bin". Enabled by "safe_mode = on", this restricts programs that can be called to the specified directory. Since Apache is running in a chroot jail with limited programs in /bin, this is a safe place to allow programs from.

The next bit of setup is not security related exactly, but it is a very convenient way to maintain the site. The server will be serving out a variety of dns aliases to the same ip. There will be one for each committee as well as a primary one for the site as a whole. Using the Apache vhost_alias you can just create a simple directory structure and then Apache will work out finding the proper directory. The directory structure will have a primary directory for the honors program and then separate directories for each committee: /home/www/files/html/honors.tntech.edu/ /home/www/files/html/honors.tntech.edu/computer /home/www/files/html/honors.tntech.edu/ecology /home/www/files/html/honors.tntech.edu/service /home/www/files/html/honors.tntech.edu/leadership Apache then will contain a vhost directive: UseCanonicalName Off VirtualDocumentRoot /files/html/%3+/%1 ]]> When a request comes in (ecology.honors.tntech.edu) Apache tries to match a directory in DocumentRoot with the last 3 parts of the name (honors.tntech.edu) and then a subdirectory under that with the first part (ecology). In /home/www/files/html/honors.tntech.edu/ there is a symlink to . called www. This means that requests for www.honors.tntech.edu and honors.tntech.edu map to the same place. This also means that www.honors.tntech.edu/ecology, honors.tntech.edu/ecology and ecology.honors.tntech.edu all map to the same place. This setup will not work correctly for honors.tntech.edu because the search for the first part fails. It is therefore necessary to have a single normal NameVirtualHost to catch that special case. DocumentRoot /files/html/honors.tntech.edu ServerName www.honors.tntech.edu ]]>

CVS is going to be used to hold the authoritative version of all the files in the site. A checked out copy of the repository is then going to be kept up to date with the repository and this is what files will be served from. Groups will be structured so that each committee will only be able to change their own pages and not be able to affect the site at large. Also the repository will be set up so that changes can only be appended; files cannot be deleted by regular users so an attacker could change the website but the last version will always be preserved.

This setup is going to require a variety of groups to be created both for the webserver and for the cvs server. There is a primary group that everyone who is doing web work will be a member of called www. Each committee will have its own group and for convenience sake these groups are prefaced with www- (www-ecology, www-social, www-computer, etc.) Also there are certain shared resources that are not associated with a particular committee but that they will all have access to (stylesheets, backgrounds, images) and there are groups for these as well also prefaced with www- (www-styles, www-images, etc.) CVS also has a special set of groups to control access. CVS looks for a special group called cvsadmin when changes are requested to the configuration files. If that group exists then the current user must be a member of that group in order to edit the configuration. Also whenever a file is checked out from the repository a lock is created to prevent another process writing to the file while it is being accessed. Usually these locks are created in the same directory structure as the repository but to do this anyone you want to read from the repository will also need write access to those directories. This is a problem since we want apache to read from those directories but not to be able to write to them. The solution is to create a separate directory structure for the locks and then allow everyone you want to read access to that structure including apache. The group that will own that directory structure will be called cvsread.

Now that the basic groups have been created with addgroup the repository can be created. The first step is to create a directory to hold it. This directory is later going to be accessed via a web-based CVS browser so it needs to be inside of the apache chroot jail. mkdir /home/www/files/cvs Now that it is created it needs to have the control files created with: cvs -d /home/www/files/cvs init There is now a working repository at /home/www/files/cvs. To allow people read only access to the repository without having to give them write access to the directory structure we will change the locks directory directive in the configuration. It is tempting to just edit /home/www/files/cvs/CVSROOT/config. This will in fact change the behavior of CVS but it is not the proper way to change the configuration. All of CVS's configuration files are version controlled so to edit then you check them out and make your changes on a checked out copy. Any user can check out the control files but if the cvsadmin group has been created only users in that group will be allowed to commit (and root cannot commit under any circumstances.) If you have been doing your setup as root you will have to allow the user you plan to make the changes as to create a lock in order to change the setup. You do this by creating the cvsadmin group and adding them to it: groupadd cvsadmin USER_TO_CHANGE=username usermod -G $(id -G $USER_TO_CHANGE | sed -e "s/ /,/g"),cvsadmin $USER_TO_CHANGE (If the user has any other supplemental groups usermod requires them to be listed in a comma separated list or they will be removed.) Then give cvsadmin group ownership of the configuration directory: chown :cvsadmin /home/www/files/cvs/CVSROOT Finally, from that user account checkout the control files: su - username cvs -d /home/www/files/cvs checkout CVSROOT Once you have the control files checked out edit CVSROOT/config and add the line: LockDir=/home/www/files/cvs-locks You should create the lock directory and let the cvsread write to it: mkdir /home/www/files/cvs-locks chown :cvsread /home/www/files/cvs-locks chmod g+ws /home/www/files/cvs-locks Because different users will be accessing this directory and creating subdirectories and you want the whole thing to be accessible to all the members of the cvsread group. Setting the set-gid (sgid) bit on the directory solves this problem. On an executable sgid causes the program to run with the gid of the owner of the program, for a directory though it causes any subdirectories created under that directory to be owned by the owner of the parent directory and also to have the same permissions as the parent.

All of the sites will be held in one project called websites. Getting this set up is fairly simple: export CVSROOT=/home/www/files/cvs mkdir websites cd websites cvs import websites honors start cd .. rm -rf websites cvs checkout websites cd websites mkdir honors.tntech.edu cvs add honors.tntech.edu cd honors.tntech.edu wget http://www.google.com cvs add index.html cvs commit -m "Test google page" cd /home/www/files cvs checkout -d html websites cd html/honors.tntech.edu ln -s . www chown -R apache:apache /home/www/files/html/ If apache is running like it was set up before, http://www.honors.tntech.edu should now be up with Google's page. The file webroot-update.sh which will be run after every checkin has the -P option to update. This will prune empty directories which keeps things cleaner overall, but if you add a new site it will not show up until there is at least one file on it. The symlink to . named www as mentioned earlier allows mod_vhost to serve up the same page for both honors.tntech.edu and www.honors.tntech.edu.

You are going to have a checked out version of the repository at /home/www/files/html and from this apache is going to serve requests. This copy always needs to be up to date with the repository so we will put an option into CVSROOT/loginfo (which is run after every commit) to update Apache's copy of the files. An issue here is that the script in loginfo runs as the user performing the commit. Because the files in Apache's copy are owned by apache the user will not have the rights to perform the update. There are a couple of ways to deal with the, one is to give the user access rights to Apache's copy by making the files group writable and then add everyone maintaining the site to that group. Another way is to use sudo to run the update as apache. sudo is more secure and easier to maintain. So to CVSROOT/loginfo we add: DEFAULT (sleep 2; sudo -u apache /home/www/files/webroot-update.sh; &) >> /home/www/var/log/cvs-update.log 2>&1 And then /home/www/files/webroot-update.sh looks like: #!/bin/sh cd /home/www/files/html; /usr/bin/cvs -Q update -d -P; The permissions on apache-update.sh then need to be set with chown apache:apache /home/www/files/apache-update.sh. It is also necessary to inform sudo to allow members of the www group to run the webroot-update script. Changes to the sudo configuration are done using visudo which will bring up the configuration and then syntax check it before committing. Simple add the line: %www ALL=(apache) NOPASSWD: /home/www/bin/webroot-update.sh

The cvs access is going to be a little bit strange because there are two different ways that it will be accessed. On the one hand ViewCVS will be accessing the repository from one of Apache's subprocesses and thus within the chroot jail. Regular users however will be accessing the repository from outside of the jail and so it is necessary to set up a series of symlinks, so that the two directory structures appear the same. Rather than clutter the root filesystem with symlinks we will create an artificial structure inside of /home/www. Outside of the chroot it appears as though the repository is at /home/www/files/cvs/. From within it seems as though it appears to be at /files/cvs. Therefore it is necessary to create some structure such that /home/www/home/www is a relative symlink to /home/www. One very simple way to do it is to: cd /home/www ln -s . home ln -s . www /home/www/home/www is now the same place as /home/www. This will work, but there is another setup that makes a little more sense. In order for apache to allow access of user's home directories (http://honors.tntech.edu/~will/) those directories have to be inside the chroot. In order to place these files on the large storage partition they are at /home/www/files/home (or within the chroot they would appear to be at /files/home.) It makes sense to link these home directories to /home in the chroot: cd /home/www ln -s files/home Now to make the two sets of directories line up: cd /home/www/files/home ln -s ../.. www Now from within and without the chroot /home/www points to the same directory (and thus /home/www/files/cvs is the same place.)

Now that the basic setup is complete some user accounts can be added. Users will have very limited access to the system. Specifically they will be able to: Checkout files from the repository via cvs Access their personal webpages via windows filesharing Change their passwords Other than that they should have no access to the server. This is accomplished in a fairly straightforward way. As an example I will add a new user. His name is Mark Spence and he is working with someone else on developing a page for the Associate Director of the program. This little shell script will add him as a user: /dev/null && echo "Username $NEW_USER already present in /etc/passwd" && exit 1 [ -d $BASEDIR/$NEW_USER ] && echo "$BASEDIR/$NEW_USER already exists" && exit 1 read -p "User's Full Name: " FULLNAME read -p "User's NT Id: " NT_ID useradd -g www -G cvsread -d "$BASEDIR/$NEW_USER" -s /bin/rbash -c "$FULLNAME" -M -n $NEW_USER smbadduser "$NEW_USER:$NT_ID" mkdir $BASEDIR/$NEW_USER cd $BASEDIR/$NEW_USER ln -s $REL_PATH/passwd ln -s $REL_PATH/smbpasswd ln -s $REL_PATH/cvs ln -s $REL_PATH/quota ln -s $REL_PATH/du echo "# .bash_profile" > .bash_profile echo "# $FULLNAME ($NEW_USER) added " $(date +"%A, %Y %B %d, %T (%-I:%M:%S %p)") >> .bash_profile echo export PATH=. >> .bash_profile mkdir www chown -R $NEW_USER:www . chmod -R a-w . chattr +i . .bash_profile ]]> You might not have rbash set up on your system. If you don't, just create a symlink to bash named rbash. This is a restricted shell and the user is not allowed to change directories or set the environment variables SHELL, PATH, ENV, or BASH_ENV. Also they can't run commands with a / in them, so setting their path to . and not allowing them to own their home directory fairly effectively limits them to only running the programs symlinked into their home directory (passwd, smbpasswd and cvs). Because the path is set to . the user cannot be allowed to write to her home directory, else she might put a new shell there and execute it. Also the directory and bash profile are set to immutable because even though they don't have access to the chmod command via a shell they can still change permissions via the windows filesharing. This box is intended only as a webserver and not for any other type of storage. There will be another computer running where they can have user accounts to learn on. I am also imposing 150mb quotas on everyone which ought to be more than enough for most anything they would like to do. edquota mspence And the input looks something like: Disk quotas for user mspence (uid 517): Filesystem blocks soft hard inodes soft hard /dev/hdb4 16 150000 150000 7 0 0 Conveniently enough this information is also available via the windows explorer properties if his home directory is mapped via smb. This creates a basic account for him. To add a branch in the main webroot for them do: cvs -d /home/www/files/cvs checkout -l websites/honors.tntech.edu mkdir rita_barnes cvs add rita_barnes/ This directory will not show up on the server immediately because the way that the repository is updated prunes empty directories. In order for this directory to be available for Mark to update it needs to be owned by his group: groupadd www-rita_barnes usermod -G $(id -G mspence | sed -e "s/ /,/g"),www-rita_barnes mspence chown :www-rita_barnes /home/www/files/cvs/websites/honors.tntech.edu/rita_barnes Once I get a password to Mark Spence he should now be able to log in via ssh and make changes to that part of the repository. A simple session either from another Linux box or from cygwin might look like: export CVS_RSH=ssh cvs -d ":ext:mspence@honors.tntech.edu:/home/www/files/cvs/" checkout websites/honors.tntech.edu/rita_barnes cd websites/honors.tntech.edu/rita_barnes/ echo "hi" > test.txt cvs add test.txt cvs commit -m "Testing adding a file" test.txt lynx http://www.honors.tntech.edu/rita_barnes/test.txt This same basic process is available from any platform that has a cvs client and a ssh client.