russell(_at_)cscorp(_dot_)com (Russell Van Tassell) writes:
I have a feeling that this is a "stupid" question and is probably answered
in one of the hundreds of peices of documentation that I haven't read word-
for-word, but, I'm stuck (and it's late).
This isn't a stupid question, but rather an obscure one. You're on the
right track though.
Right now I'm trying to invoke formail/sendmail from /etc/procmailrc when
procmail is being used as a local delivery agent on a Sun Solaris 2.5 box
running v8.6 of sendmail... and /bin/csh is complaining "permission denied"
in the procmail log (although it is none-to-specific about what is getting
denied (or why)).
Now, the recipe, when invoked from a user's procmailrc file works just fine
and nothing abnormal happens... (see the "simple" vacation rule in the
procmailex guide for an example of something that breaks - not that exactly,
but, it still breaks).
Can I assume that this is some stupid setuid problem with csh... it is
somehow deciding it's "insecure" so it's basically telling me to "go to
hell" or some such??? Is there a simple way around it? (or even a more
complex way?)
The problem is that Solaris's csh is smart enough to know that setuid
shell scripts are a security hole unless certain extra provisions are
taken to protect the script from various spoofs. Rather than have csh
simply setuid to it's real user-ID when it starts (anything that'll
make csh scripting harder is a feature) they added an option "-b" that
tells csh it's okay to run setuid, please take those extra paranoid
steps. Personally, I still wouldn't trust it.
Now, if procmail is setuid root and is running in delivery more (the
-d flag was passed to it), then while procmail is processing
/etc/procmailrc, its effective user-ID won't necessarly match its real
user-ID. Programs invoked from /etc/procmailrc will inherit this
condition which to them is indistinguishable from themselves being
setuid.
The solution I would suggest to this is two-fold: use DROPPRIVS as soon
as possible, and set SHELL to /bin/sh at the top of /etc/procmailrc (or
even compile in that assignment). Using csh for anything
non-interactive is a mistake in my book, and should be swiftly punished
by rm'ing /bin/csh and replacing it with a link to /bin/sh. As
documented in the procmailrc(5) manpage, setting DROPPRIVS to "yes"
will cause procmail to drop it's special privileges. This is obviously
the safer choice for those situation where you don't need to be doing
things as root. If your /etc/procmailrc _doesn't_ start with
"DROPPRIVS = yes", then you should be staring at it _very_ hard before
saving it.
I'll note that Solaris's /bin/sh will drop any special privileges
unless invoked with the -p flag, so if you really need commands to be
running as root, then you'll need to either make sure that procmail is
skipping /bin/sh totally (if there's no shell processing needed) or
change SHELLFLAGS to "-pc".
Philip Guenther