Benjamin, In response to your mail of Friday, May 31, 2002 1:24:17 AM:
BP> Hello. Thanks for the feedback. BP> 3.23.36 is a bit outdated by now Sure -- actually that's why I was vague about the side-issue (below) and why I checked the changelogs for an explicit fix to my main problem. BP> been several bug fixes regarding GRANT/REVOKE since then. So you BP> may consider upgrading and check if you find the problems still BP> reproducable. Okay - I can live with the workaround for now anyway, and I'll get a later version next time I sync. with RPM's. I generally only update on a needs basis, most notably for security, as I like to keep things stable and conservative where I can :) >> (a) [SIDE ISSUE] BP> That is a bit too vague to be useful. Can you provide a repeatable BP> test case? I'm content that I had a few glitchy behaviours, but rather than spend time in detail I just wanted to give a "heads-up" and if I find the problem explicitly in an up-to-date version then I'll report more fully. This part just for info. BP> You know that the privileges have different points when they are BP> evaluated again? I had read that, but I took it to refer to automatic regeneration when grant/revoke weren't used (unlike the older approach where manual adjustment in mysql.* never updated), and assumed that grant/revoke being explicit were always clever enough to tell user sessions what the state of play was... ...so, you're saying that grant/revoke changes may not be effective immediately in accordance with these reload points? That would explain a lot of it. There was one case where granting/revoking table-specific and/or database-wide privileges left something table-specific in place when it should have (in a single session - not across users logged in or whatever), but I can't remember the specifics. As I say, I'll leave these details until I have a newer version. Meanwhile... >> (b) [MAIN ISSUE] This was the real subject of my posting. BP> I cannot reproduce the problem you described on 3.23.46: Sounds like it's prolly fixed then. Might that be the case even without an entry in the changelog? I guess general correction in source code that wasn't done to address a specific problem may not be listed whilst fixing the problem. Although, just for clarification... mysql>> GRANT FILE ON *.* TO philemon@localhost; [..snip..] mysql>> SELECT * FROM db WHERE db='yasg' AND user='philemon' \G BP> *************************** 1. row *************************** BP> Select_priv: Y BP> Insert_priv: Y BP> Update_priv: Y BP> Delete_priv: Y I only had *NO* privileges in the 'db' table for the user. Like I mentioned, the privilege I granted was *just* for the table from which I wanted to select data, so no entry in 'db', but an entry in 'table_priv' with just 'select' privilege specified. Do you want a copy of the transcript I've posted to the list a number of times over the last couple of days? It may help illustrate the steps to reproduce. BP> Well, sometimes bugs have side-effects which are not obvious by BP> the description in the change history. There have been several BP> fixes to the handling of files and to the privilege system. So BP> IMHO 3.23.36 is not an appropriate version for discussing issues BP> with these and you should either upgrade or provide repeatable BP> test cases (as I have done for you in one case), so that others BP> with newer versions can verify it against their systems. Yes, I started with a repeatable test-case in a detailed transcript but I think my initial posting didn't catch people's attention <g> so maybe I would need to copy that to you again for a quick stab with a newer version... ...or wait until I upgrade and I'll re-try. Cheers folks, James. --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
