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.