MAY Version 2.08
                         ----------------
     ========= >>>>>>>> README ---- IMPORTANT <<<<<<<<< ==========


Security
========
MAY comes with a large and dangerous security hole built into it.  If
you do not understand this hole and how to manage it, do NOT use MAY.
The author assumes no liability for any damages or loss in connection
with the use of MAY.  You are hereby forwarned, and assume all risks.

Description of Security Hole
----------------------------
The MAY system allows programs to be started and run remotely on any
system on which there is a running Maydaemon.  In the current design of
MAY, the programs are started with, and run with the same priveledges,
access rights, and authority as the Maydaemon.   Furthermore, in the
current design, there is no attempt made to verify the authority or
access rights of any remote requests presented to the maydaemon.  The
maydaemon will attempt to honour any request presented to it.

What does this mean? If you run the Maydaemon with root priveledges, and
a malicious or careless user asks the Maydaemon to run /bin/sh, and
feeds the string "cd /; rm -r *" to it, then it WILL happen:  every file
in the file system will be erased.  If the user requests that 
"/etc/shutdown" be run, then it will run, and your system WILL
shutdown.  Furthermore, it takes little or no brains to figure out how
to do this, based on the MAY documentation & example programs.  So -- be
forewarned.

Therefore, you do NOT want to run MAY with root priveledges in a 
hostile environment (such as computer systems accessible to
undergraduates, or on machines not protected from the internet).

Note that starting the maydaemon from a boot script (such as /etc/rc)
or from the inetd (/etc/inetd) will automatically give the maydaemon
root priveledges.

What To Do About It
-------------------
Create a separate user account for the maydaemon, making sure that it
has no group priveledges that you wouldn't want a general user to have.
This should provide sufficient security for most environments.  The
author beleives that running MAY in this fashion does not introduce any
security holes that are not already present in your machine.


Apologies
---------
The author regrets this short-fall in today's era of security
consiousness. The author welcomes any suggestions for how to improve
security, and is interested in donations of code implementing security
measures for MAY -- e.g. a Kerberos based MAY.