Ability to seperate site from e-mails with seperate linux user
We would like to have on the same server two seperate linux users, one for the website and one for the e-mails.
If a company wants to provide access to a 3rd party to modify their website they often don't want to give them access to their e-mails. Not just from the user interface but also from the file access.
If à website is hacked, the hacker shouldn't be able to get access to the e-mails.
If a host wants to put seperate quotas on e-mail then on the website this would also become possible.
Seperate quotas could mean that the website cannot stop e-mail accounts from working and e-mail accounts can't stop the website either.
Both accounts would have the same domains, just different usernames.
An option to allow the first cpanel user to access the second user's e-mail settings would be nice so admins can descide if this is possible or not. And another option to say if both accounts share the same disk limits or not.
This would also imply a true e-mail only account type as all non e-mail fonctions would have to be disabled on one account type and all e-mail fonctions disabled on the website only type.
Prevelege escalation could be done if the server admin want's a single login for the main cpanel user to have access to both e-mail and website settings, while still keeping the files seperate.
After careful consideration we have decided this is a feature we will not implement. You're asking for a fundamental change in the design and architecture of cPanel & WHM. We prefer the design where everything that belongs to a cPanel account is owned by that account. Introducing secondary system users that map to the same cPanel account introduces a significant complexity that will impede future evolution of the platform and increases support costs, among other reasons.
Part of this feature is very similar to the request for secondary users (http://features.cpanel.net/responses/multiple-cpanel-logins-cpanel-subusers) which we are interested in implementing at some point.
After careful consideration we have decided this is a feature we will not implement. You're asking for a fundamental change in the design and architecture of cPanel & WHM. We prefer the design where everything that belongs to a cPanel account is owned by that account. Introducing secondary system users that map to the same cPanel account introduces a significant complexity that will impede future evolution of the platform and increases support costs, among other reasons.
Part of this feature is very similar to the request for secondary users (http://features.cpanel.net/responses/multiple-cpanel-logins-cpanel-subusers) which we are interested in implementing at some point.
After careful consideration we have decided this is a feature we will not implement. You're asking for a fundamental change in the design and architecture of cPanel & WHM. We prefer the design where everything that belongs to a cPanel account is owned by that account. Introducing secondary system users that map to the same cPanel account introduces a significant complexity that will impede future evolution of the platform and increases support costs, among other reasons.
Part of this feature is very similar to the request for secondary users (http://features.cpanel.net/responses/multiple-cpanel-logins-cpanel-subusers) which we are interested in implementing at some point.
After careful consideration we have decided this is a feature we will not implement. You're asking for a fundamental change in the design and architecture of cPanel & WHM. We prefer the design where everything that belongs to a cPanel account is owned by that account. Introducing secondary system users that map to the same cPanel account introduces a significant complexity that will impede future evolution of the platform and increases support costs, among other reasons.
Part of this feature is very similar to the request for secondary users (http://features.cpanel.net/responses/multiple-cpanel-logins-cpanel-subusers) which we are interested in implementing at some point.
Replies have been locked on this page!