Oracle Glogin.sql and Login.sql Security Risk

The glogin.sql and login.sql files are a very useful tool.  They are now read after each CONNECT command not just when sqlplus is started.  You can modify your LOGIN file just as you would any other script, this makes it really useful, for example:

SET SQLP "_USER >"

Oracle's documentation shows the options here.
Tom Kyte showed how the new to 11.2 exitcommit works, which would have it's uses too.

But I have a number of concerns about the potential of these files if they are left unsecured.

If the sqlplus restriction level is set to 3, the login.sql is not read. (sqlplus -r 3)
I think this would be a bit too restrictive though as it seems to wipe out a lot of stuff I would want.

The commands edit, get, host, save ,spool ,start (also @ and @@) and store are all disabled with level 3 restrict as well, so I have to assume that the files must be read by Oracle.

glogin.sql is global and lives in $ORACLE_HOME/sqlplus/admin. If there are no login.sql files that Oracle can find it will use this glogin.sql. I haven't found a way to ask ORACLE to use an alternative location for glogin.sql.

To find the login.sql on unix (tested on AIX) it first looks at the environment variable ORACLE_PATH, then your current location, then the environment variable SQLPATH.
On windows with Registry Key or environment variable SQLPATH and ORACLE_PATH set it will always still look first in the current directory for a login.sql, then goes to the SQLPATH variable.  It ignores ORACLE_PATH altogether.  Oracle say this is a feature of  Oracle on Windows not a complete oversight!  They've even added it to the documentation so they don't have to fix it!

It is important that the file is appropriately controlled.  My issue is that a user could leave a spurious login.sql in a folder that says something like:

"set feedback off
Grant myuser DBA
/
set feedback on"

He might leave that file in a place where he believes the DBA might start sqlplus from like a badly secured $ORACLE_HOME, /tmp or  just  / (C:).  If he fires up sqlplus whilst in that path he will have granted me DBA without realising it.  By ensuring that ORACLE defaults to read the $ORACLE_PATH/login.sql this risk is lessened.

So if I want to try to force ORACLE to only look in one place for a login.sql on unix I just export ORACLE_PATH in the .profile.  When the user calls sqlplus ORACLE automatically uses the login.sql in the $ORACLE_PATH. I know that the user could then change ORACLE_PATH but the gate is at least closed if not bolted. On Windows at the moment, I can't.

Of course any well audited and monitored system will pick this up (you would hope) but in the meantime he could log on and have a ball!

It is always important to lock down your oracle binary directories, you don't want any Tom, Dick or Harry in there, it's just not necessary but Oracle is just not helping here by still leaving this back door unlocked.

*update April 2011 : Oracle have accepted an enhancement request to do something with this but it has been a big battle.
Please leave any further information about how to mitigate this in the comments, I'd be really happy to hear about it.