Re: mutt, getmail procmail
On 7/13/07, Woodchuck [EMAIL PROTECTED] wrote:
On Fri, 13 Jul 2007, Philip Guenther wrote:
...
Why do people think that hardcoding the paths to normal programs is a
good thing? Why not just say formail and let the shell do the work?
Sometimes users do nutty things with aliases. Then they need to
undo the nuttiness when they need default behavior. Even worse is
the sort who defines new meanings for common commands and places
them high in the PATH, or defining nutty shell functions named
for standard commands. (Such as the nutty implementation of undelete
functionality through a redefinition of rm to a mv of a file to a
hidden directory.)
If someone wants to provide undelete by putting their own version of
'rm' early in their path, that's their right and any consequences are
their own to deal with. A complaint that your script used my version
of 'rm'! is properly responded to by saying you're welcome!.
That goes for a lot of possible nuttiness: UNIX has always provided
users all the rope they wanted, whether for holding up sails or
hanging themselves.
Yes, issues may arise when there are programs running with elevated
privileges. For example, procmail contains a bunch of paranoia about
file and directory ownership because it is often running as users that
don't even know it exists, such as when it is configured as the local
delivery agent. Once procmail decides that your $HOME/.procmailrc can
be trusted, however, that rcfile is perfectly free to pull in or run
whatever it wants, safe or not. Similarly, procmail carefully cleans
the environment whenever it's run with options that could make it
change its uid or gid, as it supports being installed setuid root or
setgid mail, but your rcfile can load the environment back up with
whatever scary hooks you prefer (LD_PRELOAD? Sure!).
One good bit of news is that $ENV files will no longer be an issue for
non-interactive programs as of OpenBSD 4.2, as the ksh in CVS no
longer sources your $ENV file when non-interactive. That's a Single
Unix Spec requirement, so other systems are (oh so slowly) moving that
way too. That means aliases won't bite scripts unless the scripts go
out of their way to be targets.
The default ksh.kshrc shipped with OpenBSD contains nutty aliases:
...which will only be experienced by users that have it manually
enabled in their .profile, either by themselves or their admins. And
even for them it won't be an issue after 4.2 or on other systems that
comply with the SUS requirements on the shell.
On a multiuser system, even one with one human user, uncertainty
arises about what flavor of nuttiness is in play for each user in
all possible contexts. (Is my user name that invokes ksh subject
to the same nuttiness as the one that invokes zsh or csh?)
Why would your shell matter? It's not like scripts are run by your
current shell (again, unless they make themselves a target).
Also, slipping a dubious substitution for a system command into
another user's ~/bin, on ill-administered or trusty systems, can
lead to various forms of good-natured, puckish mischief. (Suppose
I can substitute an arbitary executable named vi or rm into
your ~/bin.)
Setting a PATH and using fully qualified path names for utilities
may be classified as a sort of prudent practice. Whether it is
best practice I do not judge.
If you have write access a directory that's early in my path, then I
have ceded to you control of my account. I fail to see how using full
paths for only some programs (not all) and only in scripts (not in
interactive shells) is going to fix that. Darn, you can't slip in via
formail because I used $FORMAIL, so you'll have to do it via the plain
'rm' or 'cat'. Or better, put that evil version of 'tset' or 'stty'
in my path and wait for me to log in.
(Setting PATH or using full paths _is_ valid, in my opinion, for
dealing with systems where incompatible versions of system utilities
are present, such as Solaris with its ancient awk and
/usr/ucb/{df,ps,chown,...}. shakes fist at Sun. That's a matter of
porting rather than security, as it is aimed at the brokenness that
has been encountered and not as an attempt to make something work when
the user can't be trusted.)
Philip Guenther
Re: mutt, getmail procmail
On 7/13/07, Denny White [EMAIL PROTECTED] wrote: ... PATH=$HOME/bin:$HOME:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:. That line is probably unnecessary. Unless you can point to a specific program that your .procmailrc uses that is not in the default PATH set by procmail, why change it? FORMAIL=/usr/local/bin/formail Why do people think that hardcoding the paths to normal programs is a good thing? Why not just say formail and let the shell do the work? SENDMAIL=/usr/sbin/sendmail Remove that line: procmail sets that for you. ($SENDMAIL is a historical wart that exists only because sendmail was originally installed into a directory (/usr/lib) that wasn't in anyone's path.) LOCKFILE=$HOME/.lockmail Ugh. Do you know what that LOCKFILE assignment does? Unless you have a specific need for it (and I don't see anything in your .procmailrc that does), you should remove it. If you don't know what it does, then go read the procmailrc(5) manpage and then remove that line. # Anything that has not been delivered by now will go to $DEFAULT # using LOCKFILE=$DEFAULT$LOCKEXT That comment is not correct for at least two reasons: 1) the locking of $DEFAULT$LOCKEXT is only done if $DEFAULT names an actual file and not a directory, and 2) it doesn't (re)use LOCKFILE: you can hold both global lock and a local lock When I take procmail out of .getmailrc just download everything to my inbox, there's no problem. The problem starts every time I try to use procmail. Below is typical output of a getmail session: 2007-07-13 14:23:31 Delivery error (command procmail 17884 error (0, procmail: [17884] Fri Jul 13 14:23:31 2007 procmail: Assigning MAILDIR=/home/dennyboy/Mail procmail: Assigning DEFAULT=/home/dennyboy/Mail/inbox procmail: Assigning PMDIR=/home/dennyboy/.procmail procmail: Assigning LOGFILE=/home/dennyboy/.procmail/.procmail-log procmail: Opening /home/dennyboy/.procmail/.procmail-log)) 2007-07-13 14:23:31 msg 13/13 (2274 bytes) msgid UID54784-1149445332 from [EMAIL PROTECTED] ... It looks like the complaint from getmail is that procmail is writing stuff to its stderr. That's occurring because you set VERBOSE to on before you set LOGFILE. Either remove the assignment to VERBOSE or move it to after the LOGFILE assignment (or move the LOGFILE assignment to before the VERBOSE assignement, of course). Philip Guenther
[EMAIL PROTECTED]: Re: mutt, getmail procmail]
-- ___ ___ / __/ _ \/ __/__ / _\ \/ // / _//___/ / /___//_/ /_/ [ 1987 - 2007 ] http://sdf.lonestar.org Public Access Unix System === GnuPG key : 0x1644E79A | http://wwwkeys.nl.pgp.net Fingerprint: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A === Date: Fri, 13 Jul 2007 19:26:52 -0500 From: Denny White [EMAIL PROTECTED] To: Philip Guenther [EMAIL PROTECTED] Subject: Re: mutt, getmail procmail Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] X-GPG-PUBLIC_KEY: http://wwwkeys.nl.pgp.net X-GPG-FINGERPRINT: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A User-Agent: Mutt/1.5.12-2006-07-14 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 13, 2007 at 02:44:48PM -0600, Philip Guenther wrote: On 7/13/07, Denny White [EMAIL PROTECTED] wrote: ... PATH=$HOME/bin:$HOME:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:. That line is probably unnecessary. Unless you can point to a specific program that your .procmailrc uses that is not in the default PATH set by procmail, why change it? FORMAIL=/usr/local/bin/formail Why do people think that hardcoding the paths to normal programs is a good thing? Why not just say formail and let the shell do the work? SENDMAIL=/usr/sbin/sendmail Remove that line: procmail sets that for you. ($SENDMAIL is a historical wart that exists only because sendmail was originally installed into a directory (/usr/lib) that wasn't in anyone's path.) LOCKFILE=$HOME/.lockmail Ugh. Do you know what that LOCKFILE assignment does? Unless you have a specific need for it (and I don't see anything in your .procmailrc that does), you should remove it. If you don't know what it does, then go read the procmailrc(5) manpage and then remove that line. # Anything that has not been delivered by now will go to $DEFAULT # using LOCKFILE=$DEFAULT$LOCKEXT That comment is not correct for at least two reasons: 1) the locking of $DEFAULT$LOCKEXT is only done if $DEFAULT names an actual file and not a directory, and 2) it doesn't (re)use LOCKFILE: you can hold both global lock and a local lock When I take procmail out of .getmailrc just download everything to my inbox, there's no problem. The problem starts every time I try to use procmail. Below is typical output of a getmail session: 2007-07-13 14:23:31 Delivery error (command procmail 17884 error (0, procmail: [17884] Fri Jul 13 14:23:31 2007 procmail: Assigning MAILDIR=/home/dennyboy/Mail procmail: Assigning DEFAULT=/home/dennyboy/Mail/inbox procmail: Assigning PMDIR=/home/dennyboy/.procmail procmail: Assigning LOGFILE=/home/dennyboy/.procmail/.procmail-log procmail: Opening /home/dennyboy/.procmail/.procmail-log)) 2007-07-13 14:23:31 msg 13/13 (2274 bytes) msgid UID54784-1149445332 from [EMAIL PROTECTED] ... It looks like the complaint from getmail is that procmail is writing stuff to its stderr. That's occurring because you set VERBOSE to on before you set LOGFILE. Either remove the assignment to VERBOSE or move it to after the LOGFILE assignment (or move the LOGFILE assignment to before the VERBOSE assignement, of course). Philip Guenther Philip, Thank you. Followed your advice. Pertinent section below. It works. No more error messages, messages get filtered properly, life is good. I had set it the previous way that made the errors I guess out of misunderstanding the documentation and samples I had found. Anyways, thanks again, very much appreciated. Denny White = VERBOSE=off PMDIR=$HOME/.procmail LOGFILE=$PMDIR/.procmail-log MAILDIR=$HOME/Mail # You'd better make sure it exists DEFAULT=$MAILDIR/inbox COMSAT=no PER=([EMAIL PROTECTED]|[EMAIL PROTECTED]) FBSDALL=([EMAIL PROTECTED]|[EMAIL PROTECTED]) OBSDALL=([EMAIL PROTECTED]) :0 *$ ^From:.*$PER per/ :0 *$ ^From:.*$FBSDALL fbsd/ :0 *$ ^From:.*$OBSDALL obsd/ == -- ___ ___ / __/ _ \/ __/__ / _\ \/ // / _//___/ / /___//_/ /_/ [ 1987 - 2007 ] http://sdf.lonestar.org Public Access Unix System === GnuPG key : 0x1644E79A | http://wwwkeys.nl.pgp.net Fingerprint: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A === iD8DBQFGmBdFy0Ty5RZE55oRApFQAJsF+g7qjWSlT9Zc/vfOVvuQpRQqbwCfQQAy ju0BjC1doukS9IFk18GOeec= =wuzL -END PGP SIGNATURE-
Re: mutt, getmail procmail
On Fri, 13 Jul 2007, Philip Guenther wrote: On 7/13/07, Denny White [EMAIL PROTECTED] wrote: ... PATH=$HOME/bin:$HOME:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:. That line is probably unnecessary. Unless you can point to a specific program that your .procmailrc uses that is not in the default PATH set by procmail, why change it? FORMAIL=/usr/local/bin/formail Why do people think that hardcoding the paths to normal programs is a good thing? Why not just say formail and let the shell do the work? Sometimes users do nutty things with aliases. Then they need to undo the nuttiness when they need default behavior. Even worse is the sort who defines new meanings for common commands and places them high in the PATH, or defining nutty shell functions named for standard commands. (Such as the nutty implementation of undelete functionality through a redefinition of rm to a mv of a file to a hidden directory.) The default ksh.kshrc shipped with OpenBSD contains nutty aliases: alias su=wsu alias cd=wcd alias ftp=wftp alias ssh=wssh alias telnet=wtelnet alias rlogin=wrlogin alias ls='ls -gCF' wxxx are nutty shell functions, given the best of both kinds of nuttiness. Once this nuttiness is invited in, the author of shell scripts and configuration files becomes justifiably nervous about their scope. On a multiuser system, even one with one human user, uncertainty arises about what flavor of nuttiness is in play for each user in all possible contexts. (Is my user name that invokes ksh subject to the same nuttiness as the one that invokes zsh or csh?) Also, slipping a dubious substitution for a system command into another user's ~/bin, on ill-administered or trusty systems, can lead to various forms of good-natured, puckish mischief. (Suppose I can substitute an arbitary executable named vi or rm into your ~/bin.) Setting a PATH and using fully qualified path names for utilities may be classified as a sort of prudent practice. Whether it is best practice I do not judge. Dave
