[753] in Info-AFS_Redistribution
mail & afs
daemon@ATHENA.MIT.EDU (Michael Niksch)
Fri May 8 05:30:06 1992
Date: Fri, 8 May 92 10:15:03 SET
From: "Michael Niksch" <nik@zurich.ibm.com>
To: Info-AFS@transarc.com
Ref: Note from Jamey Maze
> Has anyone tried implementing a generic mail server ...
> - each workstation has a symlink from /usr/spool/mail to say
> /afs/cell/spool/mail
> - incoming mail is routed to the mail server, which is running sendmail
> under an account named say "postmaster" that has acl write access to
> the spool files
> - each user spool file is actually a symlink to a file in an afs
> directory which has read/write access granted only to that specific
> user and postmaster
We do exactly this:
ln -s /afs/zurich.ibm.com/spool/mail/nik /usr/spool/mail/nik # link to AFS
ln -s .nik/spoolfile /afs/zurich.ibm.com/spool/mail/nik# dir level ACLs
fs sa /afs/zurich.ibm.com/spool/mail/.nik system:postman rlw -clear # P.O.
fs sa /afs/zurich.ibm.com/spool/mail/.nik nik rlw # addressee
fs sa /afs/zurich.ibm.com/spool/mail/.nik system:anyuser l # see below
echo nik@mailer.zurich.ibm.com > ~nik/.forward # ~nik is in AFS
On mailer.zurich.ibm.com, root holds a token in the system:postman group.
sendmail daemon runs from init as root, outside PAGs. Hence it has postman
authority for whatever it does as root. This works fine for any remote mail
sent to the mailer. However, mail originating at a userid on the mailer
machine is a special problem, since it is never seen by sendmail, but directly
delivered by the sending user invoking bellmail. bellmail is also setuid root,
but in this case it will run in a PAG and not have postman authority. We solve
this with a shell script front end to bellmail, which is a dirty hack, but
works quite well. If there is no need to deliver any mail originating at the
mailer machine, I would avoid this modification. system:anyuser l privilege
turned out to be quite necessary in certain situations. This is because
bellmail apparently checks the current spoolfile without root authority, and
hence without access to the token. If it cannot stat the spoolfile, it assumes
it is empty. It will then successfully deliver the new piece of mail (after
gaining root privilege), but overwrite whatever was in the spoolfile before.
system:anyuser l should not be a security problem, since it allows others no
more than just telling how much mail somebody has got, and the latest access.
Currently, I am quite satisfied with this solution. However, you have to be
aware that trouble will occur when the AFS spool.mail volume or the user's
.forward file is unavailable. You should try to make sure that all mail is
addressed to the mailer machine right from the origin, because with .forward,
you will still depend on the forwarding machine being up.
Michael Niksch
