Password Recovery function immediately changes password without confirming by email

patch is attached that applies cleanly against:

lp:ubuntu/maverick/eucalyptus

revno 173. This is a complete patch that resolves this security problem and has been tested against the corresponding upstream version of eucalyptus 2.0

Confirmed issue on a brand-new install of Maverick Eucalyptus (2.0+bzr1241-0ubuntu4).

Installed Eucalyptus 2.0+bzr1241-0ubuntu4.1 and rebooted all machines to start fresh. Then I:

1. tested logging in with the test user I created and the new password: success
2. logged out, and selected "Recover the password";
3. Entered userId and new password, selected "Recover password": FAIL (Error! Insufficient parameters)
3. Again selected "Recover the password"
4. Entered email address and new password, selected "Recover password": FAIL (Error! Insufficient parameters)

Carlos,

Something isn't quite right. The new password-recovery procedure does not ask you for the new password until you click on a confirmation link in the email message. When you click on "Recover password", the system should ask you for login and email address, both of which are required. Is that not what you see? In that case, either you are not fully re-deploying the code after applying the patch or your browser has the old Javascript client-side code cached. Could check on that? Thanks!

Hi Dmitrii,

No, that was not what I saw -- so it stands to reason it was probably the cache biting me. Will test again when I get back from Turkey Day.

Thanks for the heads up.

Just as a belated update, the caching seems to be server side.

Tested using two different browsers:
Firefox before the upgrade
 -> Firefox after the upgrade (old login view seen)
Chromium after the upgrade (old login view seen)

Restart eucalyptus... same behavior.

Restart server (!), new login view seen. Clearly, another service or some cache is cleared on boot. We should really try and reproduce this behavior.

################

The secondary issue which is concerning me, is the email From: field uses "n/a@neptune" (where neptune is the local hostname).... This will fail with many mail servers, and the initial (post upgrade) login of admin suggests the admin password will be used via the "admin-email-change-text" text.

Thanks

Regarding the second point, I just attempted it again.. and it did use the correct From: address. :/

Retested, brand new install of Maverick and Euca:

1. on Euca 2.0+bzr1241-0ubuntu4 (standard Maverick) added a new user, and immediately went to "Recover password". Reset the password
2. Confirmed the new password immediately works.

3. Upgraded Euca to 2.0+bzr1241-0ubuntu4.1 (which forces an application restart), and immediately went to "Recover password". The *same* page as before the update (with the new password fields) is shown.
4. Started Chromium, and went to "Recover password". The *same* page as before the update (with the new password fields) is shown.

Now, I *never* used Chromium to access Euca (in fact, I almost never used Chromium at all). Ergo, this is caching server-side.

Looking at the server... this seems to be under /var/run/eucalyptus. I will reboot now, and check again.

Indeed, after a server restart /var/run/eucalyptus is cleaned up (and, in fact, I do not see any of the *.cache.* files I saw before).

Going into "Recover password" again -- there is no prompt for new password; now there are prompts only for userId and email address (both now are required; before the update *either* userId *or* email address were required.

The email is generated providing a link to update the password. The 'From' field is correctly set.

So... it works. There is this bit about server-side caching: I do not see the /var/run/eucalyptus/*.cache.* files anymore, so something else changed. But needing to restart the server to clean up the "old" cache seems excessive.

Now, for a regression test.

No regressions seen on a 500-instances run.

Would -> rm /var/run/eucalyptus/*.cache.* , be enough to clear the server side caching and mean that a reboot isn't required?

Thanks for testing it, Carlos! And your analysis, Dave, is spot on. Specifically, here is what I would suggest adding to post-install script:

  - stop the CLC
  - rm -rf /var/run/eucalyptus/webapp
  - start the CLC

The cache files you were seeing are in 'webapp' and we might as well wipe out all of them to be safe. The CLC will repopulate that directory.

As for the "n/a" email address, I suspect you were seeing that at a point when admin's email address has not been set yet. If password recovery is initiated after fully configuring the system, this should not happen.

Confirmed the new version works correctly. This is now 'verification-done', really ;-)

http://www.ubuntu.com/usn/usn-1033-1