DANGER! Re: Privilege.ace - updated

DANGER: See warning below! ->From: Lester Knutsen <lester@access.digex.net> ->Subject: Privilege.ace - updated ->To: informix-list@rmy.emory.edu ->Date: Sun, 23 Jan 1994 00:06:46 -0500 (EST) -> ->Hello, -> ->The following is the updated version of privileg.ace, an ace report to ->print database, tables and views privileges by user. The updated version ->allows you to select users or tables ( or all users and tables by ->pressing return at the prompts ) and shows grant option privileges and ->reference prvileges. -> ->Its set up for the stores5 database, but since it only needs the ->systemtables it will compile with any database, just change the ->database section of the ace report. Once its compiled you ->can run it with any database by: sacego -d database_name privileg ->Where database_name is any database in your path -> ->Regards - Lester -> ->############################################################################# -># Lester Knutsen lester@access.digex.net # -># Advanced DataTools Corporation Voice: 703-256-0267 # -># Control you Informix database security with DB Privileges # ->############################################################################# (ACE program omitted) Lester's tool does a good job of what it is supposed to do, EXCEPT it contains one very DANGEROUS error. It uses a temporary table named `users'. My database contained (note the past tense) a permanent table also named `users'. When I ran Lester's tool against it, the report failed, stating that there already was a table with that name. However, as part of the normal program clean-up, the ACE program *DELETED* my permanent table!!!! I did not notice this problem immediately. I modified the report to use table `users2' instead of `users', rebuilt it, and reran it. This is how I know the tool works well. Based on this experience, I offer several suggestions: 1. Anyone who wants to use this tool should change the name of the temp table `users' to something else: `users2', `usertmp2', whatever. 2. People who post tools to the net should use less "obvious" names for temp tables. Try to include something in the name that will reduce the likeli- hood of colliding with an existing table name. For example, I consider `users' to be an "obvious" table name, which might already exist, while `usertmp1' or `user_qj_2' seem less likely to be permanent tables. This naming technique is not perfect, but it will REDUCE the chance of problems. 3. DBAs (myself included) should be less trusting of tools that they pull off the net. They should check for temp table name collisions, etc., etc. I have the highest regard for Lester's work, based on his many useful postings. This lulled me into having a sense of safety regarding this tool. I ran it after giving it only the most cursory review, and did not notice this disastrous name collision. 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!) \\ /________________________) (____________________________\\