Oracle Reports desname Bug fixed with Fusion Middleware 11g

This time I come back with an old stuff, which I publish nearly 4 years ago (ups, I'm getting old): The famous Oracle Reports desname Bug, my White Paper concerning this can be found under following Link A Security Hole in Oracle Application Server (Reports) and how to ... (Website of my previous employer). Due to this bug (which was never fixed from Oracle in the Oracle Application Server 10g) it was/is possible to override any file to which the oracle user got access (details see in my mentioned White Paper).

And now start claping Oracle introduce in the Oracle Reports 11g (Part of the Oracle Fusion Middleware 11g) a new Configuration Element <folderAccess> with which we can limit the read and write access for the Reports Server :-) Cool ...

The <folderAccess> Element can be defined in the $DOMAIN_NAME/servers/WLS_REPORTS/stage/reports/reports/configuration/rwserver.conf Configuration File for In-Process Servers or in the $ORACLE_INSTANCE/config/ReportsServerComponent/<reports_name>/rwserver.conf Configuration File for Standalone Reports Servers:

<folderAccess>
   <read>/u01/applications/demoapp/reports</read>
   <write>/u01/applications/reports_output</write>
</folderAccess>

With the Sub-Element <read> we can define to which directories the Reports Server got read access (multiple directories can be added separated with a semicolon) and the most important Sub-Element <write> defines to which directories the Reports Server got write access (multiple directories can be added separated with a semicolon). So an Oracle Reports Call with the option destype=file and desname=<target_output_dir> can only write output files to the defined write-Directory: no chance to damage other files outside this directory :-)

So, that's really a good reason to move to Oracle Reports 11g