On 07/25/2004 03:27 PM, Daniel Morgan said:
> Joe wrote:
>
>>On 07/24/2004 06:41 PM, Daniel Morgan said:
>>
>>
>>>Joe wrote:
>>>
>>>
>>>>On 07/20/2004 11:25 PM, Hans Forbrich said:
>>>>
>>>>
>>>>>...
>>>>>5) I can think of no valid reason, at least effective Oracle8i, to
>>>>>attempt
>>>>>ANY coding against SYS. Playing at that level is roughly equivalent to
>>>>>coding against the kernel data structures of a proprietary (closed
>>>>>source)
>>>>>OS.
>>>>
>>>>
>>>>
>>>>Does a password_verify_function still have to be owned by SYS? If
>>>>so, I wish oracle would change that.
>>>>
>>>
>>>
>>>Why? A strong desire to compromise security?
>>
>>
>>
>>Not at all - why do you suggest that?
>>
>>If I need to update the password verify function across 800+ instances,
>>and o7_dictionary_accessibility=false as it should be, it can be a pain
>>to connect as sys across that many servers. If the function could be
>>created in another schema, it's pretty easy for me to loop through all
>>800 instances from one central place, and do the create or replace.
>>Also, since exp/imp doesn't handle sys objects like a normal schema,
>>it's just one more thing that you have to handle differently.
>>
>>Actually, I wish Oracle would add some more profile parameters such as
>>minimum_length=6 and non_alpha_required=2, so you could do a much better
>>job without the verify_function.
>
>
> And also easy for someone else to do it too. Inflicting damage not just
> in one place but in all.
If someone other than a DBA could get at, and modify a password
verify function, regardless of who owns it, then there are bigger
problems to worry about!
> Seems to me it would be better to invest the time and have a more secure
> environment. Of course there is always OPS$ORACLE.
What about ops$oracle? I'm not sure what you mean. It can't create
a password verify function as SYS either. I just think that Oracle
Corp can do a few things to make a DBA's life easier, and still
maintain security.
--
Joe
http://www.joekaz.net/
http://www.cafeshops.com/joekaz
Received on Mon Jul 26 2004 - 18:59:47 CDT
