procmail
[Top] [All Lists]

Re: rc compatibility?

1999-12-17 12:09:34
gary(_at_)Intrepid(_dot_)Com (Gary Funck) writes:
On Dec 17, 11:44am, Philip Guenther wrote:

I do have a followup question.  Multiple permission changes to the rcfile
didn't seem to have an effect.  I tried 755, 600, 777; but when I changed
the home directory to 755 that did the trick.  With the home directory at
755, the permissions of the rcfile didn't matter; it worked whether the
rcfile was group writeable or not.  We're running Solaris 2.6 and we call

Hmm, how exactly are you invoking procmail?  Procmail only checks group
permissions when no rcfile was specified on the command line, causing it
to use the default rcfile.

And perhaps when -m is specified on the command line?

The rcfile specified on the command when using mailfilter mode (-m) is
not checked for group writability.  The "security violations" mentioned
on the manpage with regards to -m are only involved when specifying an
rcfile under /etc/procmailrcs/


I don't know if it was the presence/lack of -m, but I know that when I
switched to 3.14, that a shell script which had been working, that
built a temporary procmail .rc file was failing with permission
checks, because the .rc file was written into /tmp, which is obviously
world writeable.  When I changed the script to create the temp. .rc

Unless your system allows users to give away files with chown() (lose
lose!) directories with the sticky-bit set are considered fine regardless
of other permissions.  That test was broken, however, in versions 3.13
and 3.13.1.


file under my home dir, the complaint went away.  Personally, I would
have liked to see a switch that let me disable the permission checks.

You can already disable the checking.  Putting an rcfile on the command
line disables group checking.  Specifying a relative rcfile on the
command line disables _all_ checks.  That's _plenty_ of rope to hang
yourself with.

If you find that procmail doesn't want to trust an rcfile that you
think is provably safe, please email to <bug(_at_)procmail(_dot_)org> an *exact*
description of the permissions on the file, the directory containing the
file, the command line used to invoke procmail, the procmail version,
and the output of "procmail -v".


Philip, separate question - the blurb on the updated FAQ said it would
recommend that folks not upgrade to 3.14, but the only thing that I saw
was the prob. with home dir. permissions, and Red Hat's config.  Is
that the only prob.  to woory about?

The homedir permissions + Red Hat was a version 3.13.1 problem.  If it
cropped up again in 3.14 that would be news to me.  Version 3.14 broke
compilation on some (older) systems, changed the log format of '!' actions
and subtly broke the semantics of the 'flow-control flags' with doubly
nested blocks.  There were also a couple problems in the maildir support.


Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>