Tuesday, December 3, 2002 02:08 PM
Interesting problem. Actually it has been a problem ever since remote access to email was first implemented.
I think your best bet is to have the password change form merely submit a request, to a queue (maybe via email, or via some item queue system if you have one), that a responsible human sys admin will read and act upon (somebody who is already logging in regularly to the server host, able to either "su" or run "sudo" etc., to perform operations like "passwd" to change other users' passwords).
The application server is not running as the same user (locally on the server host) that the email client wants to change the password for.
On a totally insecure sandbox skunkworks system where the application server was running as root, it could just do the runtime exec itself, of the "passwd" command. Don't do this!
If you were somehow allowing the client users to connect to the server in other ways, to perform other operations e.g. via "ssh", then you could let them change their passwords that way. Don't do this, not unless they already need to do other things directly on the server!
If the Linux user that your Application Server is running as (e.g. "tomcat4" or whatever) had the privileges maybe to run "sudo", in order to do a runtime exec of the "passwd" command for the client user, then you could have a secure form submit, over https, to an action servlet which would do the runtime exec.
I'm not sure about the security implications of such an arrangement though.
So I still think the best bet is to submit a secure form with the password change request, and have a human sysadmin read it and act upon it.