==============
Change the aliases file to be group writable, and change the group on
it to a group that only this user is a member of. Then give him or
her sudo access to /bin/newaliases to re-read in the modified aliases
file.
==============
There were many variations on using the "include:" capability of sendmail
in the aliases file.
Examples:
mygroup: :include:/internet/http/www/mygroup
----------------
repsall: :include:/disk2/samba/maillist/repsall.txt
owner-repsall: pamt
----------------
You can source a list of aliases from his home directory or other file,
which is controlled by him, in the form:
alias: :include:filename
man aliases has detailed information on that as well as on setting up
an owner of a mailing list, which you might also need.
==============
I've run into a similar problem. The only thing I could think of
was to create a small script, owned by root with 700 permissions,
that simply vi'ed the file. In your case /etc/mail/aliases.
(the person was concerned this may be a security problem)
===============
I don't have a copy of sudo nearby, but I seem to recall that
with newer versions you could control arguments as well as commands.
-----------
sudo allows you to specify commands and arguments that a user can execute. so,
just specify this user can vi /etc/mail/aliases.
-----------
In /etc/sudoers put
/bin/vi /etc/mail/aliases
as one of the users sudo commands.
-----------
Create a script that executes with this command
vi /etc/mail/aliases
and give him via sudo access to run only this script. However, if from vi the
user executes:
:w 'filename',
and the user sudo is emulating can modify this file, then you can not
prevent this from happening.
===============
The way I got around this was with a root cron job. The modified aliases file
was always in a certain directory, and the cron job checked that directory
every so often for an updated file. if one existed, the cron job moved the
changed version to the right place and did newaliases, etc...
================
Another mechanism, if he really needs an aliases file, is that the new
sendmails support multiple aliases files. (As configured in the sendmail.cf
file.) If your sendmail support this, simply give him an aliases file that
is writeable by him. (Again, I'd place his aliases file as the last one, to
minimize problems.)
=================
How's your C coding? :)
There is a command called vipw under /usr/ucb/bin. It is an old bsd-ism,
that alowed a little buffering for editing the /etc/passwd file. Basically
it copies it somewhere (/tmp/something) lets them edit it, and then copies
it back. Something along those lines might work for you.
==================
Maybe you can set an ACL on the file that grants access specifically to the
user in question?
==================
Alternatively, if you're using NIS+ you can
create a mailadmin NIS+ group and make them a member; allow them to
create new aliases and control some of the existing ones (but not
eseential ones such as PostMaster).
==================
-- Judith Reed jreed@appliedtheory.com