Ken Jones wrote:
Here are three suggested ways of specifying relative paths. What do you folks think?
user directory relative [EMAIL PROTECTED]/path
domain directory relative domain/path
I think I can do everything I need to do with just those two. I would prefer you NEVER, EVER allow ANY file or directory access above some domain's directory. (~vpopmail/domains/somedomain.com) Less chance of someone hacking your server through the daemon.
If you can supply just those choices, there is no reason to let the daemon leak the real directory structure of the server out to the world or accept full paths, which would reduce the number of things you have to send to the user, and simplify replies from the user.
Just to be sure:
domain.com/ = ~vpopmail/domains/domain.com/
[EMAIL PROTECTED]/ = ~vpopmail/domains/domain.com/rick/
If you have lots of domains and users and have triggered directory hashing it might be:
maybe ~vpopmaild/domains/C/domain.com/S/rick/
The nice thing is the user doesn't have to know the real path.
vpopmail home relative ~vpopmail/path
Why?
I haven't implemented spam/virus checking yet, so maybe it requires access outside the someone's domain directory , but I would be surprised if there was no way to arrange things so you never need access above that point.
If you allow full paths, please make sure the daemon can't do nasty things like
write_file /home/vpopmail/bin/vdelivermail
That is a lot more work than just limiting file access to the domain directory of a specified domain or below is a big step forward for security. It should also make authorization checks much easier as you don't have to parse incoming full paths, and can just verify domain or [EMAIL PROTECTED] is valid for the current user.
Rick
