Re: REVOKE

->Date: Mon, 16 May 94 09:41:11 PDT ->From: johnl@informix.com (Jonathan Leffler) ->To: bgirard@crash.cts.com, informix-list@rmy.emory.edu ->Subject: Re: REVOKE -> ->>From: bgirard@crash.cts.com (Brian Girard) ->>Subject: REVOKE ->>Date: Fri, 13 May 1994 22:40:19 GMT ->> ->>Hello fellow informix users: ->> ->> I am having great trouble with using the revoke command. Every so often ->>a user will "accidently" remove a row(s) and I must unload and load from back- ->>up. This is ok if the incident is discovered relatively soon. But to combat ->>this problem, I am trying to revoke all table priviledges except for update. ->>I have dba priviledges and tried this to no avail: ->> ->> revoke delete,alter,index, on clients from brian ->> ->>I went in as user brian (who has connect priviledges only) and I was still ->>able to delete rows?? ->> ->>We are using Informix 2.10.03f on SCO sysV r3.2.4 with MPX 3.0 -> ->This is an old version running on a much newer system. -> ->The first, and key, issue is "Who granted the permissions?" You can ->investigate this by selecting information from SysTables and SysTabAuth; -> ->SELECT T.TabName, T.TabId, A.Grantor, A.Grantee, A.TabAuth { modified } ->FROM SysTables T, SysTabAuth A ->WHERE T.Tabid = A.Tabid ->AND T.TabName = "clients"; -> ->Now, if there is a row with Grantee = "brian" or Grantee = "public" which ->gives insert, delete, etc privileges, then regardless of what you say as ->someone else, brian has the access privileges. So the actual privileges ->enjoyed by brian are the inclusive OR of all the privileges granted by ->individuals. -> ... much good stuff from Jonathan deleted ... -> If this doesn't work, you'll have to get the ->actual table owner to revoke the privileges. ... more stuff deleted ... Brian, It will probably make the Informix folks shudder, but I have a more direct method for you that works well with version 2.10.03f. Note: I do not think this technique works for versions 4.x and up. Informix has become much more protective of their system catalogs in recent versions, and with good reason. Once you use Jonathan's SELECT (as I've modified it) to find the involved rows in table systabauth, then as a user with DBA privilege you can: DELETE FROM systabauth WHERE tabid = ... AND grantor = ... AND grantee = "brian" { and if necessary, public } Direct modification of the system catalogs is a touchy business. Proceed with extreme care. Regards, Alan ___________________________ ______________________| R. Alan Popiel |__________________________ \\ Internet: | Martin Marietta, SLS | / \\ alan@den.mmc.com | P.O. Box 179, M/S 3810 | Std disclaimers apply. / )Voice: | Denver, CO 80201-0179 USA | ( / 303-977-9998 |___________________________| (But you knew that!) \\ /________________________) (____________________________\\