Re: Revoking select on a single table

2004-08-30 Thread Michael Stassen
[EMAIL PROTECTED] wrote: I was blocked from running a SELECT query against secrettable. I could INSERT values but not DELETE them. I reason that this is because DELETE ... WHERE ... requires a SELECT to be run on the table to identify the rows to get rid of. The error I got when trying to delete

Re: Revoking select on a single table

2004-08-30 Thread SGreen
Yes, I think that _may_ solve your problem. Try granting only INSERT and UPDATE on the table then grant only SELECT permission on the ID column (I assume it's autoincrementing?) and the user_id column. If you don't make the user_id column visible, how will you ever discover the correct ID to up

Re: Revoking select on a single table

2004-08-30 Thread Todd Charron
Sorry to reply yet again, but I think I have the solution. After doing all we have said above I added grant select(ID_Num) on sampdb.secrettable to 'user'@'localhost' identified by 'password'; and of course updates and deletes are done via update secrettable set secretinfo="blah" where ID_Num

Re: Revoking select on a single table

2004-08-30 Thread Todd Charron
Thinking about this some more, it might be possible to achieve what my last email suggests by allowing select on the primary key column. Or would that set us back again? Thoughts? Todd -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lis

Re: Revoking select on a single table

2004-08-30 Thread Todd Charron
On Monday 30 August 2004 4:08 pm, [EMAIL PROTECTED] wrote: > I think that INSERT-only would be as good as we could hope for as I have > been having a very hard time trying to think of a valid business reason > why a user would be allowed to either UPDATE or DELETE rows from a table > where they

Re: Revoking select on a single table

2004-08-30 Thread SGreen
I think that INSERT-only would be as good as we could hope for as I have been having a very hard time trying to think of a valid business reason why a user would be allowed to either UPDATE or DELETE rows from a table where they weren't allowed to even see the data. However I can think of sever

Re: Revoking select on a single table

2004-08-30 Thread Todd Charron
> GRANT usage on samp.* to 'permtest'@'localhost' identified by 'password'; > GRANT insert, update, delete on samp.secrettable to > 'permtest'@'localhost'; > GRANT select, insert, update, delete on samp.Account to > 'permtest'@'localhost'; > This worked much better for me, though it's not a per