Hello,
On Tue, 24 Apr 2001, Alan Cox wrote:
> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
>
> email -> sendmail
> sendmail 'its local' -> spool
>
> user:
> get_mail | procmail
> mutt
>
> The mail server doesnt need to run procmail. If you wanted to run mail batches
> through on a regular basis you can use cron for it, or leave a daemon running
Oh, well, cron is just another suid program.
This example would just be the ideal scenario for posix- or novell-style
ACLs in the filesystem.
You run the MDA/MTA under some mailerdaemon uid. And then a user can
explicitly give this daemon read access to .procmail etc. You can also
give the MTA (and nobody else) write access to /var/spool/mail. The MDA
then gives the specifical user full access to the spoolfile when creating
it, or adding mail to it. And the user can fetch his mail and truncate or
delete the file just as he and his software is used to.
There are much more things with ACLs, especially in workgroup environments
(That's why I loved the old Novel server in our university), but they
never got into the kernel. And as far as I (as a non-hacker) understand,
the fields reserved for this feature were dropped for the large file
support, so we may never see ACLs.
Gruß,
Markus
--
| Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist.
+---------------------------------------. ,---------------->
http://www.uni-ulm.de/~s_mschab/ \ /
mailto:[EMAIL PROTECTED] \_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
