[OpenAFS] fetchmail / afs / segfault revisited

Charles Clancy security@xauth.net
Sun, 17 Mar 2002 18:55:40 -0600 (CST)

> It turns out that the villain is now procmail. It cant seem to read my
> ~/.procmailrc for some reason so it must not have a token:

Isn't procmail intended to automatically process incoming mail?  I've
never used it, but I believe that's what it's for.  It can be run by
sendmail from a "|/path/to/procmail" in your .forward, correct?  Or, are
you running it from the command line to process mail you've just fetched
(with fetchmail, I assume)?

In the first case, it wouldn't work at all, because sendmail doesn't have
access to your AFS token.  The second case should work.

First thing I noticed is that procmail is by default installed setuid.

In several different places, I tries to setuid:

ismene:~/procmail-3.22/src> grep -in setuid *.c
lockfile.c:72:  if(setuid(uid)||geteuid()!=uid)           /* resist setuid
operation */
misc.c:83:/* On systems with `capabilities', setuid/setgid can fail for
root! */
misc.c:100:     if(setuid(uid))                              /* "This
cannot happen" */
procmail.c:498: setuid(uid);                       /* make sure we have
enough space */

You might try removing it's attempts to change UID, and recompile.
An example of using pagsh to run procmail:

ismene:~> id
uid=100(tclancy) gid=100(clancy) groups=100(clancy)
ismene:~> pagsh -c /bin/tcsh
ismene:~> id
uid=100(tclancy) gid=100(clancy) groups=33536,32524,100(clancy)
ismene:~> klog
ismene:~> procmail -whatever -options ...

Notice the list of groups is longer -- which indicates you now have a PAG.
Then, when you do a klog to get a token that will be with all the child
processes of your shell, regardless of their attempts to setuid.

[ t charles clancy ]--[ tclancy@uiuc.edu ]--[ www.uiuc.edu/~tclancy ]