Friday, August 05, 2005
Connected Thinking
I noticed on Chris Foot's blog, and confirmed by way of the readme, that in 10gR2 the CONNECT role has been neutered.
Historically I, and many others, have advocated the banning of the CONNECT and RESOURCE roles, instead recommending using user-created roles or granting required privileges directly to user accounts. The CONNECT role has been a particular bug bear since it rather suggests that it allows a user to connect to a database, rather than its actual purpose of allowing a user to connect to a database and then create objects, database links to remote databases, alter sessions to set diagnostic events and so on. In 10gr2 CONNECT has one privilege and one only - CREATE SESSION.
I applaud this decision. Its brave, because it will break applications where required privileges haven't been thought about, but it is the right thing to do.
I also like the enhancements to security for external procedures run as jobs, though rather than grant the new privilege CREATE EXTERNAL JOB to all users with the CREATE JOB privilege on upgrade I'd have preferred a report that stated something like
The following users have the ability to schedule execution of operating system scripts and commands. For security reasons this privilege has been removed by default in 10g Release 2. If a user requires this functionality please grant the new CREATE EXTERNAL JOB privilege to that account.
5 Comments
Historically I, and many others, have advocated the banning of the CONNECT and RESOURCE roles, instead recommending using user-created roles or granting required privileges directly to user accounts. The CONNECT role has been a particular bug bear since it rather suggests that it allows a user to connect to a database, rather than its actual purpose of allowing a user to connect to a database and then create objects, database links to remote databases, alter sessions to set diagnostic events and so on. In 10gr2 CONNECT has one privilege and one only - CREATE SESSION.
I applaud this decision. Its brave, because it will break applications where required privileges haven't been thought about, but it is the right thing to do.
I also like the enhancements to security for external procedures run as jobs, though rather than grant the new privilege CREATE EXTERNAL JOB to all users with the CREATE JOB privilege on upgrade I'd have preferred a report that stated something like
The following users have the ability to schedule execution of operating system scripts and commands. For security reasons this privilege has been removed by default in 10g Release 2. If a user requires this functionality please grant the new CREATE EXTERNAL JOB privilege to that account.
5 Comments:
absolutely shrek. Security should always be transparent and easily understood. if it isn't it won't be used or it will be used incorrectly.
One of the things that has worried me is the ability to set current_schema in a session. The possibilities for altered security states are mind-blowing. Of course I understand the need for something like current_schema, with applications nowadays including in excess of 25000 tables: I can't imagine anyone creating that many GRANTs and SYNONYMs.
But for example: what happens to my session's original grants (implied or otherwise)? What if I have one setting for resource manager and the new schema (set by my login trigger) has another: which should be the end result? Which one *is* the end result?
But for example: what happens to my session's original grants (implied or otherwise)? What if I have one setting for resource manager and the new schema (set by my login trigger) has another: which should be the end result? Which one *is* the end result?
Great! I have been trying to clean up the environment here and the CONNECT role was one where it has way too many privs required just to have an account connect and access the database.
Why has a role - CONNECT with only one privilege? Why not just grant CREATE SESSION?
Guns kill people; therefore, they should be abolished. Isn't this the same logic Oracle is using? Wouldn't it be better to educate versus eradicate?
Guns kill people; therefore, they should be abolished. Isn't this the same logic Oracle is using? Wouldn't it be better to educate versus eradicate?
Manual Trackback:
A german post complaining about the now missing CREATE VIEW privelege in the RESOURCE role, referencing this article:
IT-Blog: ORA-01031 on Create View
Gruss
Bernd
Post a Comment
A german post complaining about the now missing CREATE VIEW privelege in the RESOURCE role, referencing this article:
IT-Blog: ORA-01031 on Create View
Gruss
Bernd
# posted by 
: 3:26 AM, November 09, 2005
: 3:26 AM, November 09, 2005
