Many thanks to those who responded:
"Michael A. Crowley" <mcrowley_at_mhc.mtholyoke.edu>
Simon Greaves <censjg_at_caledonia.hw.ac.uk>
"Aylward, Mannix" <MannixAy_at_msbris.praxa.com.au>
Sid Fagan - Sublimation MAN (NID) <fagan_at_large.fnal.gov>
Paul A Sand <pas_at_hopper.unh.edu>
*** Here was my original posting:
Hello,
We recently aquired an Alpha 2100 and are looking for options to account
management. We have run a large Unix system here mainframe style with over
7,000 accounts and counting. The account add/mod/del process has been
pieced together with scripts and programs created locally.
We would like to delegate the account creation process without giving
complete super-user authority. We would also like to delay the actual file
updates (ie passwd entry) until late evening because we have experienced
problems in the past with user confusion over a "busy password file".
I would appreciate any experiences shared on this subject and will
summarize to the list.
*** Here are the responses I received:
----------------------------------------------------------------------------
From: Simon Greaves <censjg_at_caledonia.hw.ac.uk>
Paul,
We have a similar setup here, I'm currently writing a perl program to do this
stuff using signed PGP mail messages. Theory is our central registration
machine mails a signed PGP encrypted message to an account on the recipient
machine which decrypts the file, parses the account information and creates
the accounts.
Since this requires the mail filter program to run as root (or setuid) and I'm
not wholly sold on that idea, I'm considering just using the mail filter for
PGP decryption and creation of modified copies of the passwd/group/netgroup
etc files then maybe run a cron/whatever job to do the stuff that needs to be
done by root (is that any more secure?.... queue - creeping paranoia).
Whatever the final implementation, the overview here is that we run tools on a
VMS box which allow non-privelidged users (ie secretary types) to process
account requests as well as batch job account requests. The account creation
software on that host arbitrates usernames, initial password, uid, gid etc and
mails the request as a formatted message to the destination host (eg NIS
master) then (currently) a human administrator verifies the message and either
registers by hand or uses a home grown registration form (built using
expectk), hence the development of an automated system.
Simon Greaves
censjg_at_caledonia.hw.ac.uk
DDI: +44 (0)131 451 3265 Fax: +44 (0)131 451 3261
----------------------------------------------------------------------------
From: "Aylward, Mannix" <MannixAy_at_msbris.praxa.com.au>
Paul,
You could play with the set user id and set group id bit on your script, but
beware of security holes.
As for a busy /etc/passwd, you should really use the command vipw to edit
it. This will create a lock file.
Good luck,
Mannix
----------------------------------------------------------------------------
From: Sid Fagan - Sublimation MAN (NID) <fagan_at_large.fnal.gov>
Well we have an application written for that, I have to check but I
believe we can give it away especially since your email ends in edu.
It basically is a program with setuid the checks who you are and looks
in a function file see if you can do what you are trying to do. These
include adduser, rmuser, resetuser (passwd) all kinds of this types of
things. Most of these are then scripts and are run as root. I popped
this out of the cmd program, provides a little info. If you want this
let me know and I double check. A partial example of the functions
file follows..
addmember:0,0,0,0:root,fagan,*gm
adduser:0,0,0,0:root,fagan,joe
chguser:0,0,0,0:root,fagan,joe
deldata:0,0,0,0:root,fagan,joe
delmember:0,0,0,0:root,fagan,*gm
disuser:0,0,0,0:root,fagan
moduser:0,0,0,0:root,fagan
resetuser:0,0,0,0:root,fagan
reuser:0,0,0,0:root,fagan
vigr:0,0,0,0:root,fagan
vipw:0,0,0,0:root,fagan
finduser:0,0,0,0:+*
* The function table format:
* function:identity:permitted
* 'function' is the key to the entry in the FUNCTION table and also
* is the name of the executable in the LIBRARY directory
* 'identity' is a comma separated list of ruid, euid, rgid, egid
* to execute this function under, numeric and name forms permitted
* 'permitted' is a comma separated list of login names permitted
* to execute this function. '*gm' indicates a group manager
* account; i.e. a login with the same name except possibly case
* as the group name indicated by the login's gid. '*' indicates
* all users. A '-' prefix to any of the above requires that
* the user of the command be su(1)'ed to the effective login
* id from another id to use this permission entry; otherwise,
* a '+' prefix to any of the above indicates that su(1)'ed status
* is ignored.
*
* The function table must be owned by the effective uid of this program
* and must be grouped to the effective gid of this program. It must have
* no world read or write permission. It must be a regular file. The directory
* the FUNCTION table and executable reside in must be owned and grouped
* similiarly with no world read or write permission and it must be a directory. * The executable must be owned and grouped to the effective uid/gid specified
* in the functions files and must not have world read or write permissions.
*
* The function is passed the following:
* 'function' - the original 'function' argument
* 'arguments' - the original 'argument' list
* The underlying original login name as the CMDLOGIN environment variable.
* The invoking process login name as the CMDNAME environment variable.
* The underlying original group name as the CMDLGRP environment variable.
* The invoking process group name as the CMDGROUP environment variable.
* The current working directory at the time cmd was called at the CMDCWD
* environment variable
* The CMDSU environment variable to indicate whether ('1') or not ('0')
* su(1)'ed.
*
* This program is called as:
* cmd 'function' 'arguments'
-----------------------------------------------------------------------------
From: Paul A Sand <pas_at_hopper.unh.edu>
Paul --
We allow a small number of folks to submit account request files
into a specified directory. (The actual mechanism is via rcp into
a non-root ``system manager'' account. The trusted users are in the
.rhosts file.)
A cron ``account manager'' job running as root then processes the
request files in the directory periodically. The account manager does
things like create/delete accounts, add people to groups, change their
primary group, change login ID, change shell, etc.
We've been doing this for about 4 years now with no major problems,
and our user community is about the same size as yours.
-----------------------------------------------------------------------------
From: "Michael A. Crowley" <mcrowley_at_mhc.mtholyoke.edu>
What I have is a script that causes a mail message to be
sent to me with a line in it that is the proper line for
a script file to add users later.
Basically it passes a line in the form of:
adds username "Real Name, Dept" group
and these are processed, adding passwords to the line
and then does the actual addition of users. That is
another set of scripts. Those also produce a piece
of paper to return to the user.
I haven't automated the last step because I like to review
the user addition before doing the commit, but I could
separate the review and have the addition process be
run by cron in the middle of the night. You could do
something like that and thus a certain set of users
in a specific group could create the list of additions
that cron would later pick up and run.
This is all on an Ultrix machine; I haven't done this on our osf system.
However, the Ultrix password hashing to passwd.pag/passwd.dir
poses some serious problems. I don't know if it has been
corrected in osf. When you are hashing the password file,
it creates the .pag and .dir files. Once that occurs, even
though they are not yet complete, the system tries using
them and therefore begins to claim that users are not there
who should be there.
What I do is to build the hashed password files in directory
in /etc and, once done, mv them to /etc.
--
-=( Paul Wood http://astro.ocis.temple.edu/~pcwood)=-
-=( pcwood_at_uniblab.ocis.temple.edu Temple University Computer Services)=-
Received on Tue May 16 1995 - 11:31:30 NZST