Disabling webmail per email account, contribution

elbruj0,

Interesting...but I think there's some things that you should consider.

1) you're using the environment variable REMOTE_DBOWNER as the reference to the cPanel username (who would have the nvdata access list). While this will be equal to the cPanel username in almost every instance, there's no technical guarantee that it is the same...I would suspect that until cPanel makes further refinements to the DBOWNER paradigm, you should be able to use it safely...again, no guarantees

2) Your proxying the cPanel API call as root. This is not a problem in itself, only the fact that many extra precautions need to be taken; there's likely a better solution (generally speaking). So, you're authenticating your call based on a remote access hash. If you hardcode the access hash (as seems to be implied by check_webmail.php), then anyone with shell access on the system will be able to read it from the file...and thus are capable of making any API call they wish...a fatally dangerous situation. Alternative, if you were to add a call to read the file contents of root's access hash, that too would not work. The file read would fail because webmail applications are served as an under-privileged user (either cPanel user or a special system user like cpanelroundcube) and won't have adequate permissions to read the root owned file.

3) Anytime cPanel updates Horde, Roundcube, etc, your custom files (index.php and friends) will likely be removed. You'd need to hook into the `upcp` process (in the post stage of a script hook or a standardized hook) so that you files always overwrite (or apply a patch to) any updated files after maintenance has occurred.


A better, although more sophisticated, approach to getting/storing this info might be something like the following:

1) Custom cPanel Module that allows cPanel users to write to a datastore
- this would provide a custom cPanel API call that you could use for managing the data from within the cPanel UI
- the write operation would actually be a call to a privilege escalation binary

2) Private, central datastore
- have it only accessible by root
- use a privilege escalation binary for accessing it

3) Privilege escalation for access to datastore
- the special system webmail users would only be able to get a yes/no reply based on a email; the webmail apps can make a proc_open() or other system() type of call [not ideal, but doable if you're very very cautious]
- the CRUD calls necessary to manage the datastore would enforce that the requesting user only operates on domains they own.

Something like that still has some caveats but at least would be secure. It *might* be a little faster too than the network call involved with xmlapi-php, but I think that's really of little concern when compared to the secure implication.

Regards,
-DavidN

 

Both Horde and Roundcube are served under special users, cpanelhorde and cpanelroundcube respectively

you can test with something like the following at the top of horde or round cube index.php:

PHP:

var_dump(posix_getpwuid(posix_getuid()));


As for getting a definitive cPanel username account, it won't be possible without a custom escalation binary that cpanelhorde or cpanelroundcube can use. This is because the webmail runtime process/environment was designed for the email user, not the cPanel user.

REMOTE_DBOWNER will likely work in most situations; I was merely pointing it out because when you do hit that edge-case there will be no 'work-around' other than the aforementioned escalation binary.

cPanel provides the C code for an escalation binary here (as well, a variant is shipped with cPanel)

As for your last thought, this might actually work given the following:
a) the webmail runtime process has $_ENV["HOME"] which points to the cPanel user's home directory
b) you use your own file and not .cpanel/nvdata/*…something that is readable by cpanelhorde and cpanelroundcube…depending on how you accomplish this, I'm not sure if it's a good idea…that's to say if you simply made your data file world readable, it would expose email/domain info of the users if a vector to the file system becomes available...but it probably could be done such that's not the case.

You mentioned that no one has ssh access, so that helps…but there can be other vectors too. A good mantra is to never but anything of value ( or that could be leveraged in other ways) in a world readable file.