On 12/01/2010 01:35 PM, Dan wrote:
There is no setgid bit set.
I had to chmod 777 the /website/vuser directory just so that new user
creates would work otherwise when it changes uid to some virtual id
such as 2003, it would not be allowed to create anything in the
directory to begin with no matter who owned it.
What does
namei -m /website/vuser
say about it ?
777 is almost always wrong; logically, it just needs to be chown :2001
and chmod 775.
Its really problematic because even if end user creates the
/website/vuser/test.com directory ahead of time
You should not need to do that with vmailboxes.
Either the MDA or the IMAP server will create them when needed.
with correct uid and gid like postfix seems to need to work, the uids
are an autoincrement field starting at 2002 for each new added user,
so you can see how this could be cumbersome quickly.
The way postfix is currently working only feasible way to do it would
be every virtual user on system share same uid then that parent
directory could be owned by that user.
That's the usual way to host virtual mailboxes, yes.
In that system, every ftp account, imap, pop3, email account would be
owned by same id.
The same physical *system* ID, yes.
If this is not what you desire, then using virtual mailbox users makes
no sense for you at all.
Just use system users, optionally with an invalid shell if you wish to
prevent them logging in.
I'm almost considering moving to doing it that way just to avoid these
issues with postfix, as I'm really trying to see any kind of security
issues rising from a parent process forking to the same uid for
everything.
Minor to non-existent, as long as you don't go around chmodding stuff to
777.
Only one I can see is if ftp users were not chrooted to their
homedirectory they could go around deleting other users files.
Use proftpd, it does a virtual chroot.
SInce reason I am sharing same gid across all virtual users to begin
with is to chroot ftp users to their home directory, maybe any
security risk may be alleviated.
Yes - use proftpd.
A correct solution I think however for postfix would be if mkdir fails
with permission denied errors on parent directory, to change uid to
root, create directory and change permissions on it.
Absolutely not.
Postfix wil never execute commands with root privileges unless
specifically configured to do so, and only then in very limited
circumstances.
Allowing postfix to arbitrarily escalate privileges is fail.
I think I may move to sharing same virtual uid and gid for all virtual
users since ftp chroot is only security risk I can see, and if I ever
had to move users to a new system and lost permissions on all
directories would be cumbersome to chown -R each user to respective
uid again.
It sounds like you've been unnecessarily complicating things.
Setting up virtual users for multiple services is fairly easy to
accomplish, as long as you have some way of making the userdb available
to all services.
--
J.
