Re: FLASHBACK ANY TABLE

I forgot to mention - you can grant another schema access to flashback a table in another schema.

For example "grant flashback, select, delete, insert on schema.table to some_other_schema;"

So in your case you could allow the application access to flashback a specific table in another schema outside the schema user the application uses to authenticate.

Brent

On Wed, Mar 18, 2015 at 6:09 AM, Brent Day <coloradodba_at_gmail.com> wrote:

> Kumar,
>
> You are right - this is a security risk and my recommendation would be to
> never grant any "ANY" system privileges. There have been many easily
> exploitable privilege escalations bugs around the "ANY" grants. While many
> of these have been fixed provided you keep up with CPU/PSU patching. The
> flashback any privilege in the past had problems - see CVE-2012-1751. While
> this has been fixed you just never know when some patch or upgrade may
> break this again.
>
> As a general rule we do not allow any user or application account to have
> any of the ANY system privileges.
>
> If I was in your position I would get with the developers and find out
> what they are trying to accomplish and maybe find an alternative method to
> meet the requirements without granting flashback any.
>
> Hope that helps.
>
> Brent
>
>
>
> On Wed, Mar 18, 2015 at 5:50 AM, Kumar Madduri <ksmadduri_at_gmail.com>
> wrote:
>
>> Hello:
>> Our developers have requested flashback any table to be given to apps (in
>> an ebusiness environment). They would not have the apps password in
>> production. I think they are using it to build some feature in a custom
>> app.
>> Regardless of their motivation, I think this is a security risk because
>> why would a developer want this privilege in a production environment.
>>
>> I cant think like a hacker but it does not sound right to me.
>> Want to confirm with the list if I am missing something ?
>>
>> Thank you
>> Kumar
>>
>
>

--
http://www.freelists.org/webpage/oracle-l