If you dig down into the Oracle on Amazon RDS, you can find the some security restrictions. These are things that Amazon won't let you do with your database and include the following:
· Alter database
· Alter system
· Create any directory
· Drop any directory
· Grant any object privilege
· grant any privilege
· Grant any role
· Restricted session
BlueGecko notes a couple of others:
· Datapump / imp / exp FULL_DATABASE privileges
· Alter user, revoke or any DDL on SYS, SYSTEM or RDSADMIN users
· Drop tablespace RDSADMIN
· Create public synonyms for objects belonging to SYS, SYSTEM or RDSADMIN
Most of those are pretty obviously 'dangerous'. These are the items that, in an organisation with a hierarchy of DBAs, would only be available to the Top Gun. And in this environment, Amazon holds that position.
The 'CREATE ANY DIRECTORY' is one where you need to think evil before you work out why it is so dangerous. So I shall adopt the persona of the villainous toad, 'Baron Silas Greenback', sit back in my black leather chair and stroke my furry white pet while I explain the plot. Then you can escape my henchmen and save the day.
The plan is cunning in its simplicity. Simply create an Oracle directory that points to the OS directory containing the Oracle data files. Then I could use UTL_FILE to read and even update those datafiles directly, without going through the protective SQL layer. The operation through UTL_FILE is, as far as the operating system is concerned, indistinguishable from an official, controlled change through an INSERT statement.
In fact any of the Oracle database files could be accessed this way. Control files, redo logs, audit trails... In short, directory privileges are REALLY nasty things.