I know it has been reworked for 4.2, or better for every release since 4.0, but: The user management, in particular,
needs to be reworked.
- The spec is ambiguous. A canonical user id
pos_64MY_46DOMAIN could either be a kerberos principal
pos@MY.DOMAIN or a user
64_MY_46DOMAIN in some strange user mapping
- The spec is apparently unclear. When tracing through a failed registration for Item4771, counting revealed:
- 49 invocations of
forceCUID with the already escaped user id
pos_64MY_46DOMAIN. Maybe it needs to be "safe" to call
forceCUID with an already cUID-safe value, but 49 times is way to often. It must be well-defined from where in the process a request has a valid cUID. Note: This is a count for a not yet registered user whose name does not occur in any topics nor password files.
- 39 invocations of
handlesUser, 37 calls to
_getMapping, 40 calls to
fetchPass, all for the same user id.
TWikiUserMapping::userExists is broken because it always calls the current user existing (regardless of whether she is registered). It is broken again if
PasswordManager = none because it consults
fetchPass instead of TWikiUsers to find out whether a user exists.
No wonder that, after so many calls, TWiki itself has convinced itself that it knows the user and he must not register again.
I call this an "Enhancement", hoping that the user management can be "fixed" to make 4.2 somehow workable.
- 14 Oct 2007
Hararld, damn right. Good feedback. I raise this item to urgent so that it gets more attention. I consider the current implementation of
as different logins are forced on the same CUID. So by registering a well chosen login name you can break into someone else's
account and get his/her authorizations.
A public TWiki using login names is only secure if it does uses characthers
in login names. A TWikiAdmin with
will be in danger to be hiajcked by any new user registering a login name
. Both these login names are mapped to
- 12 Jun 2008
I'm not at all sure that the code in 4.2.0 actually has a security problem
- but I'm happy that Micha seems to have time to look into it.
- 12 Jun 2008
The user code you wrote, Sven, is inefficient and broken by design, which translate to a security problem.
maps two namespaces on each other: (1) login names and (2) CUIDs. However the second namespace is smaller than the first. Please, try to convince me that I am wrong and that this is not
a security problem.
- 19 Jun 2008
I'm not trying to convince you one way or the other. I'm simply looking forward to your unit tests and fixes.
- 19 Jun 2008
This is too much of a burden. Could you please do this? Last but not least, you are the original author of all this.
- 04 Jul 2008