We need to turn this report into a question, rather than a bug. This is a fundamental design issue that must be clearly documented, but cannot be fixed.
I'm trying to do that now, but Launchpad keeps timing out.
The root of the problem is that in order to re-wrap the user's ecryptfs mount passphrase, the system needs *both* the old password *and* the new password.
When root forces the change of another user's password, root is not required to enter the user's old password, and therefore the mount passphrase cannot be decrypted, before re-encrypting.
About the best we could do is print an informative message to that effect.
Or we could allow the root user to "escrow", or save a copy of each user's mount passprhase. This is how Apple solves it. But this does mean that the root user will have each non-root user's private key.
We need to turn this report into a question, rather than a bug. This is a fundamental design issue that must be clearly documented, but cannot be fixed.
I'm trying to do that now, but Launchpad keeps timing out.
The root of the problem is that in order to re-wrap the user's ecryptfs mount passphrase, the system needs *both* the old password *and* the new password.
When root forces the change of another user's password, root is not required to enter the user's old password, and therefore the mount passphrase cannot be decrypted, before re-encrypting.
About the best we could do is print an informative message to that effect.
Or we could allow the root user to "escrow", or save a copy of each user's mount passprhase. This is how Apple solves it. But this does mean that the root user will have each non-root user's private key.