At 18:59 2001-12-16 -0500, Don Hammond wrote:
function lscmd()
[snip]
Works - except dirs (and we DO want to report on dirs). Changed:
[ -f ${1:-""} ] && export file=$1 || return
to:
[ -e ${1:-""} ] && export file=$1 || return
(i.e. '-f' to '-e'), and it works as per the ls operation I was performing.
(1) unless the single quotes as used above are a bash'ism that isn't
portable to a real Bourne shell. My sh is a symlink to bash.
As it is on most of my hosts. However, on BSD where there is a native
'sh', the script barfs. That's because sh doesn't preceed function
declarations with 'function '. Remove that, and it works fine on both bash
and sh. No apparent issues with the tics.
Note that I also eliminated passing the filename argument via an env var -
one simply passes it on the commandline to perl. This also paves the way
for passing the optional permissions mask as well. If a second argument
has been passed, it is assumed to be a permissions mask (in chmod numeric
form), and the file permissions are compared against those. If they exceed
the mask limits, a warning is issued.
Would someone verify what the most appropriate permissions might be (I only
perform the check for the "significant files" at the bottom of the script,
which I've busted out into two groups - the ones that are definite security
problems, and those which are adviseable, though the script doesn't emit a
different message either way and is presently checking for the same 0755
mask on both sets of files).
Also, while the use of warn in perl might generally be a good way to emit
warnings, it also means it'll go to stderr, which means the typical report
redirection will omit it. Since we expect to be working with redirected
report output, that has been changed to a standard print call.
procdiag.sh 20011216.1829 is currently posted. Includes revised lscmd
handling, and some other collected data bits. Try it - I believe it
collects up most of the significant config bits, even if it doesn't know
the true system MTA or validate file perms.
I wasn't questioning the use of fgrep there, but pointing out that
sendmail would need a fully qualified path if not in the user's PATH,
which is probably not uncommon for non-priviledged users.
FTR, I wasn't indicating you'd questioned it -- I was merely clarifying why
it was there since it wasn't documented in the script source. I've added a
comment in the script source to reflect why the fgrep is there.
I agree that we need a proper method for hunting down sendmail (if nothing
else, borrowing the SENDMAIL setting from procmail would be a start - but
as has already been pointed out, that doesn't guarantee that it is the
actual MTA on the box -- or for that matter is any sendmail.cf we might
find the actual .cf being used). The two .cf locations I check are the
common locations for the config file to be located, but since the sustem
may have been started with an alternate configfile on the daemon
commandline, that's a wild guess anyway.
Running a 'telnet localhost 25' might be useful at least to check for a
running MTA on the local system, from which we could snarf the banner. But
then, we've got to deal with timeouts and other joy. Probably use perl for
that as well. This of course still won't identify the config file or
executable paths, but it'd be a way to indicate whether more attention
needs to be paid to the MTA config (applicable only to whether procmail is
the LDA of if the user is having troubles invoking procmail from a
.forward, or if they can't send via $SENDMAIL or !forward).
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail