Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Jeroen Geilman (jeroenadaptr.nl)
Date: Wed Dec 01 2010 - 06:58:08 CST
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.
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
Minor to non-existent, as long as you don't go around chmodding stuff to
> 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.
Postfix wil never execute commands with root privileges unless
specifically configured to do so, and only then in very limited
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.