If I remember correctly, Powerbuilder tends to use DB procedures/packages
for data manipulation - these procedures run with the privileges of the user
who owns them, rather than the user who runs them, which would explain why
your user is able to manipulate the table.
It should be preventable by revoking execute privileges on the procedures in
question.
Van Messner wrote in message ...
> A user on a company database, created before I arrived on the site,
>asked me to check his permissions on a table today. Using the security
>manager I could see he had no object or system permissions granted
>explicitly or through a role that would allow him to do anything with the
>table. However, he is able to insert, update and delete rows through a
>PowerBuilder application.
> At first I though he might be going in through PowerBuilder as some
user
>with more permisssions. But I checked his PowerBuilder setup and he is
>logging in as himself.
> Then I thought the permissions might have been granted to "public".
The
>security manager does not specifically show rights granted to public as
>such.
> So I went into SQL plus and issued every query I could think of against
>the "all" and "dba" views that have anything to do with roles, grants or
>permisssions. Rights on the table in question do not show up as having
been
>granted to public. I believe the querries work properly since I can see
>rights on many other tables granted to public.
> Do any of you have ideas on where to look further?
>
>Thanks,
>
>Van
>
>
Received on Thu Mar 04 1999 - 17:31:35 CST
