At 05:03 PM 3/14/99 -0700, Scott D. Yelich wrote:
>> All you have to do is create it as root and make it readable by the mail
>> process for the user. They can read it, but they can't replace it.
>
>*sigh* I was just waiting for this to come up.
It's actually come up quite a few times - check the archives. Most Unix
people know that the directory access is what counts and the owner of the
file doesn't stop anything. In fact I think last time it came up, we talked
about a separate $MAILHOME that was not directly accessible from ftp/shell.
>I asked this question regarding the .qmail security "reward" and was told
>that this doesn't count.
It's not doubt going to get religious, but I agree that it's not a hole. No
more than allowing pipe commands in a .forward is.
After all there are numerous ways in which shell access may be constrained,
it may exclude inbound ftp, it may exclude mail delivery it may exclude
finger access to a .plan file, it may exclude ~fred http access, it may
exclude access to some, but not all commands. Who knows what your particular
intent is? And, is it the same for every admin of every machine?
I don't see vi making magical tests to see whether you are really allowed to
execute a shell command. I don't see emacs making magical test to see
whether you are really allowed to execute a shell command, I don't see elm
or mailx or mail making a magical test to see whether you are really allowed
to execute a shell command.
That you think qmail-local has some divine way of knowing what exactly you
wish to constrain is endowing it with too much prescience.
Regards.
