MS FrontPage Caveats Note

[ra...@madhaus.utcs.utoronto.ca]

This is from the FrontPage distribution:

FrontPage must have read/write access to the web's content, configuration
files, the /usr/local/frontpage directory, and if possible, the HTTP server
process itself (to send a SIGHUP restart signal).

If your web server is using a protected port (a port less than 1025), the web
server must run as root.  See the "Security Issues" section below for some
important security concerns.  Also, see the "Restarting the Server" section
below, which describes how this limits FrontPage.

2. The FrontPage Server Extensions run under the server as a CGI program.  In
order for the FrontPage Server Extensions to send the restart signal to the
HTTP server, the server's CGI programs must run under the same user account as
the HTTP server itself.  Your choices are:

- Run both HTTP server and CGI scripts as root.  In this case, the
  UserId (if CERN) or User (if NCSA or Apache) field in your httpd.conf
  file should be set to root, and you should launch the server as root.
  This scheme is not necessarily a good idea however; for maximum UNIX
  security, as few things as possible should run as root.  See "Security
  Issues" below for more details.

 * FrontPage allows the users to upload executable CGI scripts.  If you run
   the HTTP server as root and allow the server's CGI scripts to run as root,
   authors can upload arbitrary executables and shell scripts which can be
   run with root privileges.

 * If you run the HTTP server as root, and if you allow FrontPage users
   to upload arbitrary CGI scripts, users can eventually get root privileges.

 * Authors can upload arbitrary shell scripts which can affect all webs under
   your HTTP server.

 * FrontPage's Save Results Bot can allow the user to save form results into
   a file named by a file path.  If you run the HTTP server as root,
   and allow the server's CGI scripts to run as root, authors can set up a form
   where the results are written to an arbitrary file in the file system.

 * FrontPage's Save Result Bots can allow the user to pipe form results into
   an arbitrary program.  This allows security holes identical to those
   described above.

----

Per-User Webs
=============

Per-user webs are webs located in users' home directories, typically in a
directory with a name like "public-html".  (FrontPage uses whatever
subdirectory you have set in the server's configuration file as the per-user
web directory.)  FrontPage allows you to create per-user webs.  To do this,
create webs prefixed with the "~" character (for example, ~fred).

Note, however, that the FrontPage Server Extensions run under a single user
account (the one the HTTP server's CGI scripts run as).  Therefore, this can
cause some file-access conflicts: FrontPage may not be able to write into the
per-user web directory; even if it can, users may not be able to read or
modify files from their UNIX logins that were created with FrontPage.

If you want to use FrontPage to modify per-user webs, do one of the following
when setting up per-user webs:

- Before installing FrontPage into a user's web, change the owner/group
  of all the per-user web's files to the FrontPage user/group.  Also,
  change the file access permissions to be compatible with the HTTP
  server's umask.

- Change the /etc/group file so that each user is in the FrontPage
  group.  Use a group-inclusive umask for the HTTP server.  Then, change
  the group and access modes of the user's per-user web directories and
  files so that they are writable by their group and so that their group
  is the FrontPage group.  Note however, that using this scheme will
  allow these users to modify any files in any other web under the HTTP
  server from their UNIX login.