In a multi-site installation where the tables of all sites have prefixes, in the respective tables prefix_sequences an entry acl_id with the value of 1, but without prefix is created. However, there is no table acl, there are only three different tables with prefixes: e_acl, m_acl, and w_acl.
The expected entries also all exist, i.e.:
- Table e_sequences: entry e_acl_id
- Table m_sequences: entry m_acl_id
- Table w_sequences: entry w_acl_id
However, in these tables from time to time the wrong entry acl_id with a value of 1 appears. This has happened repeatedly after I deleted this entry manually.
It is not certain that the Forum Access module causes this, but I cannot find out. I have also not found out whether the false entry is only a harmless fluke or whether it is an indication of wrong access rights being assigned. Since this could cause security breaches, I have given the issue a high priority.
Hans-Georg Michna
Comments
Comment #1
merlinofchaos commentedhttp://drupal.org/node/159091
(this is all acl.module)
Comment #2
hgmichna commentedI certainly couldn't find out, so I bugged it for both modules.
Hans-Georg
Comment #3
hgmichna commentedOh, the title of the reply changes the title of the main item! And I cannot edit. And neither the original, nor the follow-up title is displayed on the New comment page. Who has set this up? What a mess!
Anyway, what I had written was this:
How do you know it is all from the ACL module?
I certainly couldn't find out, so I bugged it for both modules.
Hans-Georg
Comment #4
merlinofchaos commentedI certainly couldn't find out, so I bugged it for both modules.
Being the author of both modules gives me a certain insight.
There isn't a title on the followup comment. Issue comments don't have titles of their own.
And: this help text is a bit of a giveaway:
"Note: modifying this value will change the title of the entire issue, not your follow-up comment."
Comment #5
hgmichna commentedOh, I overlooked both that note and your identity. Very sorry!
While you are here, the very big worry is, of course, that the bug might cause a security breach, allowing some users to view forums they aren't entitled to see.
It would be great if you could give an insight, maybe not here, but as a followup to the ACL bug report. It would be a relief to know whether or not the bug is harmless.
And thanks a lot for providing these modules in the first place! They are very useful.
Hans-Georg
Comment #6
merlinofchaos commentedThe bug is harmful on multisite installations (it's fine on single installs) where you're using the same database for the sites. However it's less of a security risk and more of an issue with making it difficult if not impossible to create new ACLs because a record will already exists when the system is performing an INSERT.
I don't believe it will provide any risk of exposure; it will make it impossible to actually add moderators, though. The fix should be relatively simple, so you can hack a temporary fix if you like.
In the acl.module code, search for the function db_next_id. There should be {}. It *should* look something like db_next_id('{acl}_acl_id');
Changing all of those will essentially reset your ACL IDs, and this will need to be fixed manually. The safest way for you to do this will be to SELECT max(acl_id) from acl;
Obviously you'll need to adjust that for prefixes. You can do this in one query (braces will represent prefixing replacement; this his how Drupal's db_query does it)
INSERT INTO {sequences} values ('{acl}_acl_id', SELECT MAX(acl_id) FROM {acl});
Comment #7
hgmichna commentedI will head over to the ACL bug report at http://drupal.org/node/159091 and append what I have done there. In short---it worked. Thanks!
Hans-Georg
Comment #8
(not verified) commented