At 14:05 2002-02-14 +0000, Edward Wildgoose wrote:
I have a some Procmail scripts that are working quite well, but I have
some variables that I would like the users to be able to adjust, eg
forwarding address, pager number.
The users all have local accounts, but can't log in to them. They have
web, mail, pop and IMAP access only.
Then uh, perhaps use an https interface?
My first thoughts are to build a quick web interface to allow users to
change these settings, but I think that this raises security problems, ie
how does the web server write to a file in the users home directory.
Don't - instead, write to a file (or DB) which a user process can access.
One thought might be to put the variables into seperate files that are
writable by the web server, and the .procmailrc has readonly access,
checks the value in the file for sanity and uses that value in the rest of
the script (eg forwarding address for e-mail). However, there must be a
neater way to do this and this still leaves some security holes.
If it comes to it, keep in mind that you can do things from /etc/procmailrc
which you cannot from within the user's own .procmailrc
I have seen this done using a small C program which runs SUID, does a
chmod and chgroup to the correct user and then writes the data. Is this a
good idea..?
I'd say NO - it becomes yet another program you need to be concerned about
exploits in because it starts as SUID root.
Another thought is that I could use procmail itself, eg send an encoded
file to the user with details in the body. This would get spotted by the
.procmailrc and update the local variables and then ditch the email
without delivering... Is there some way to make this safe without the
risk of outsiders sending in mail to the users with commands in the body...
Require users to PGP sign their commandfiles and have the scripts check the
signature?
Of course, if someone else gets their mittens on an _old_ copy of a signed
commandfile, they can send it in to that user which would change the config
back to whatever it was as of that file - the cannot CHANGE anythning in
the commandfile (otherwise the signature wouldn't validate the contents),
but they could still revert an account to an older state.
The risk of that happening are probably abount on-par with someone just
finding the user's own https and PGP signing passwords on a Post-It(tm)
stuck to the user's monitor... Such things are only as secure as the users
will allow them to be.
In all this we must assume non-technically literate users with a small
patience threshold.
Then IMAP and PGP signing aren't going to be the solution, because those
demand at least a minimal tech IQ. A web-based interface can be easily
modified in response to complaints that "this part doesn't make sense"
reports from the users.
If I were stuck with this weird need, I'd have the web interface stuff
variables into an SQL database, along with the (https) authenticated userid
(which is used as the key field). Procmail can run a program which
accesses the db using a READ-ONLY db account (using the current user, not a
passed argument for the db key), thus an exploit of that perl/c/whatever
program wouldn't lead to being able to CHANGE other user's accounts. This
prog could then create an includerc file for this user which defines
multiple variables:
:0:PROCVARS$LOCKEXT
* ! ? variablemaker $HOME/procvars.rc
{
INCLUDERC=$HOME/procvars.rc
}
The variablemaker program would do the db lookup and GENERATE the
procvars.rc file, which, if it successfully completes (zero return value),
will allow procmail to read that procvars file.
Note that if the script sees that "I've already updated" (say, the db field
has a date, and variablemaker checks that the rc file isn't newer, or it
actually reads and compares the variables), it doesn't actually have to
re-make the procvars.rc file each time, so you don't get hit with the
additional overhead of file writing. As long as there isn't an _error_,
it'd still return a sucess code.
Locking ensures that you're not updating the file while it's being read by
another procmail process.
---
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