| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Re: Stop using SYS, SYSTEM?
('binary' encoding is not supported, stored as-is)
Fed-up with these new-fangled security "experts" popping up all over the place. Pretty soon we'll have another marketing driven lot of bullshit going round. With the usual crap associated with it. Next "big thing", you know the sort...
> "Oracle provides this via SYS and SYSTEM"
>
> No, it doesn't. It has the DBA role for that. SYSTEM, I can accept as
> a DBA
> user, but not SYS; it's not a user to be used as an access mechanism;
> it's
> purpose is to be a schema - a repository.
Splitting hairs here. Point is: SYS and SYSTEM are used by DBAs all over the world. If Oracle has chosen to add AS SYSDBA to SYS as a way of reinforcing that it is only to be used for very special purposes, that only reinforces my point: used ONLY by DBAs. And very sparingly, whenever needed. That has nothing to do with security of the role itself.
> Remember the
> initial days of Oracle 9i?
I even remember the initial days of V5, let alone 9i!
>
> Take a page from our friendly neighborhood unix sys admins. Most
> systems
> require direct connect to root user on the console only;
Not quite the case. root is accessible from anywhere, unless it's been assigned to a single terminal. It's not, by default. Ask a Unix sysadmin to give up his/hers "sudo" or even "su" and watch the reaction. Nearly impossible to do any work.
Fact is: an admin user MUST have access to an admin privileged account. Call it whatever you want, root or role, who cares. If this access is directly on the console, via "sudo", via script, via auditing, via bleeding whatever, is completely the realm of semantics and policy.
If a company has a policy that says admins must be "controlled", then do it the same way ANY OTHER engineering technical task is controlled: use auditing. Trying to artificially make access harder for those that need it is absolutely counter-productive and achieves nothing. Other than the Charlie Brown wet pants syndrome: gives you a warm feeling and nobody cares.
By definition, the DBA role has certain privileges of access that are far less restrictive than anybody else. If that is granted via SYS, SYSTEM or role is not the issue. The issue is: can it be audited so that it is accountable for, if that is the policy of the company?
> follwoing a good practice and obstructing progress. A cowboy
> mentality to
> approach any such issue might be a little detrimental, I think.
>
I think the last person you can associate a "cowboy mentality" approach in relation to is me, and I resent that remark. Its not by accident I have a current top level security clearance with the Australian Defense Forces and they don't usually grant them to cowboys... I'm getting a bit fed-up with my name being intentionally or not associated with "examples": there is simply no call for that and it's very old hat.
Cheers
Nuno Souto
nsouto_at_wizofoz2k.com.au
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: nsouto_at_optusnet.com.au Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Wed Nov 12 2003 - 19:14:27 CST
 |
 |