view release on metacpan or  search on metacpan

user_manage.html  view on Meta::CPAN

% <b>perl Makefile.PL</b>
% <b>make</b>
% <b>make test</b>
% <b>make install</b>
</pre></blockquote>

This will copy the HTTPD modules to the correct location within the
Perl library directory.  You may need to be root in order to do this.

<p>

The HTTPD modules are useful in their own right. During the
installation process, Perl will have created man pages for them which
you can read with the <cite>perldoc</cite> command.  Read the manual
page for HTTPD::Realm first, then HTTPD::RealmManager.

<h3>Install the <cite>user_manage</cite> Script</h3>

Copy <cite>user_manage</cite> into your server's <cite>cgi-bin</cite>
directory, or another directory that allows CGI scripts.  Make sure
that it is executable and that the top line points to the correct
location of Perl on your system, e.g.

<blockquote><pre>
#!/usr/local/bin/perl
</pre></blockquote>

<h3>Work Out Permissions for the Password and Group Files</h3>

If you plan to run <cite>user_manage</cite> as a CGI script, then
you'll need to worry about file permissions.  When the script is
executed by the server, it runs with the server's effective user ID,
usually an unprivileged user such as "nobody".  However, this user
usually does not have permission to write to the server's password and
group files.  Thus the script will fail.  In order for the script to
be able to update password and group files, not only must it have
write access to the files themselves, but to the directory that
contains them.  This last requirement is because the script creates
lock and other temporary files within the directory.

<p>

Several workable configurations are possible:

<h4>Make <cite>user_manage</cite> Run as a SUID Script</h4>

Perl is capable of safely running scripts set-user-id (suid).  When
the script runs, Perl temporarily changes to a different user ID and
executes the script.  <cite>user_manage</cite> has been written to be
safe when running in this way.

<p>

Designate a directory that will hold the various password and group
files, for example /etc/httpd/security.  Make it owned and writable by
a specially-designated "web administrator" account, for example "www".
Now, running as root, change the ownership of <cite>user_manage</cite>
to "www" and set its "s" bit:

<blockquote><pre>
# <b>chown www user_manage</b>
# <b>chmod u+s user_manage</b>
# <b>ls -l user_manage</b>
-rwsr-xr-x   1 www   users      18928 Jan 14 03:47 user_manage*
</pre></blockquote>

In order for suid to work, this feature needs to be configured into
Perl when it is compiled.  You may need to reinstall Perl if suid was
not enabled, particularly if Perl came preinstalled on your system.
There is also a bug in perl 5.003 when running under some versions of
OSF/1 (Digital Unix) that causes suid scripts to exit silently without
producing any output.  To fix this bug, apply the patch located in the
file <a href="suid.patch">suid.patch</a> included with this
distribution to the Perl source tree and recompile.

<h4>Make <cite>user_manage</cite> Run as a SGID Script</h4>

An alternative to running the script suid is to set the set-group-id
bit instead.  This will cause the script to execute with the
permissions of its owning group.  You can then arrange for the
password and group files to reside within a group-writable directory,
such as one belonging to a web administrators' "www" group.

<p>

<blockquote><pre>
# <b>chgrp www user_manage</b>
# <b>chmod g+s user_manage</b>
# <b>ls -l user_manage</b>
-rwxr-sr-x   1 root   www      18928 Jan 14 03:47 user_manage*
</pre></blockquote>

Under this scheme it may be convenient to have the script create new
password and group files with group writable permissions.  To do this,
change the script global $CREATE_MODE to "0664".  (See <a
href="#configure_script">Configuring the Script</a>.

<h4>Keep the Password and Group Files in a Directory writable by
"nobody"</h4>

If you prefer not to run <cite>user_manage</cite> as a suid or
sgid script, you can place the password and group files in a directory
that is owned and writable by the Web server's effective user ID
and/or group.  If you wish for the password files to be modifiable
from the command line, you should also make this directory group
writable by a group that you belong to.

<p>

While this strategy is effective, it has the disadvantage that it
gives the web server and all other CGI scripts the ability to modify
the password and group files.  A remote user exploiting a security
hole in the server or one of its CGI scripts could then take advantage
of this fact to alter the password file.

<h3>Restrict Access to the Script</h3>

Because you don't want everyone in the world to view and edit
your server's password files, <cite>user_manage</cite> must be
placed under some kind of access restrictions.  You can do this
either by placing the script in a restricted directory to use