Kumar, 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@xxxxxxxxx> 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@xxxxxxxxx> > 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 >> > >