Hi Michael,
I am very sorry, I guess I was too slow now ...
I figured out that the following has been missing in the patch:
diff -ru ../gosa.orig/plugins/personal/password/password.tpl
./plugins/personal/password/password.tpl
--- ../gosa.orig/plugins/personal/password/password.tpl 2012-05-02
11:49:01.000000000 +0200
+++ ./plugins/personal/password/password.tpl 2013-11-24 19:57:49.898717332
+0100
@@ -1,12 +1,3 @@
-
-{if $SASL}
-
- <br>
- <b>{t}Your password cannot be changed from within GOsa{/t}</b>
-
-<input type="hidden" name="ignore">
-{else}
-
<script type="text/javascript" src="include/pwdStrength.js"></script>
<p>
@@ -151,5 +142,3 @@
}
updateFields();
</script>
-
-{/if}
A user can change his password fine now: A hook takes old and new
password, feeds it into kpasswd and everything is fine.
However, there is a security problem when the admin modifies a
password. In that case, the script needs more privileges, and I found
no way so far to check if the hook is indeed run by GOsa or someone
else on the webserver. (This check is possible if a password hash is
available in LDAP, because it can be checked if the new password
corresponds to the hash in LDAP which is updated first).
For the time being I will continue keeping the hash in LDAP for
that reasons. However, using SASL might make sense if malicious
use of the webserver running GOsa can be excluded.
So perhaps you can include the above with the next upload, but as this
permissions problem exists, the use of SASL seems to be not very
attractive anyway.
So again, sorry for being late and thank you for your time.
Best Regards,
Andi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
