> It's really only a problem for sites that are small enough to have all of a
> users home characteristics on one system. As soon as mail delivery is placed
> on a dedicated service away from, eg, public_html, the problem goes away.
> Until that time, they have to do work to ensure that the .qmail files cannot
> be tampered with by the user if that's what they want to restrict.
The issue is: Should users be able to modify/add their .qmail files.
Qmail seems to advertise this as a feature. Fine, it's a feature.
There is no problem when users are not allowed to modify (their) .qmail
files -- they can be owner protected (just not placed where the user has
write perms).
The issue is: Fine, users should be able to modify their .qmail files --
but they should not be able to pipe to a shell or other command.
There have been several solutions to this. Personally, I think all of
them do not go far enough. The easiest solution in my mind would be
that the email could not be piped to an arbitrary program unless it had
a certain group permission (ie: some group "qmail" something -- there
are enough of them, using one or having one more doesn't seem like it
would hurt).
What this allows is for the base qmail system to run and for piping to
be allowed on a per case basis. Then, if the piped command ever changes
and/or is full of holes, so be it.
The next step or alternative choice would be for a program not to run
unless it's registered in /var/qmail/blah/pipekeys where digical
signatures of the target pipe program are stored. If the digital
signature changes, then the pipe is not allowed. This would most likely
skip the group perms, but it would allow for a per pip check and
enabling.
Scott
ps: No, I do not have and do not plan to code either of these.
