Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: new paper on direct access in C to the SGA

RE: new paper on direct access in C to the SGA

From: Goulet, Dick <DGoulet_at_vicr.com>
Date: Tue, 15 Jun 2004 15:28:17 -0400
Message-ID: <4001DEAF7DF9BD498B58B45051FBEA650146C3CB@25exch1.vicorpower.vicr.com>


Mladen,

        Most applications that I've heard on that want to do this want to be installed by the database owner, therefore permissions are no longer a preventative. On top of all that, the SGA's contents are trade secrets of Oracle. I'm sure they are not talking about it, so those who "know" what their talking about have surmised it from experimentation. I know of enough experimenters running around sans limbs to stay away from that. And anyway, going through the database engine for something like this does not place such a high load on the system that it really matters. Not to mention that this program has to run on the local machine which then has it competing for the attention of the same CPU(s) and memory as the database. And theirs nothing I can think of that slows a system down more than having the swapper working.

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Mladen Gogala [mailto:mladen_at_wangtrading.com] Sent: Tuesday, June 15, 2004 2:47 PM
To: oracle-l_at_freelists.org
Subject: Re: new paper on direct access in C to the SGA

On 06/15/2004 02:27:12 PM, "Goulet, Dick" wrote:
> Well, I know some folks here are not going to like me very much, but I for one have little respect for those who publish such hacks and not too much more for those vendors that use them. As I've said before, if you can read a memory chunk you sure as heck can write to it as well

I have to question this statement. Shared memory protection is similar to the protection of a file. You certainly can read /boot/bzImage but, unless you have the proper privilege level, you cannot write into it. Here is what shmget manpage says about the protection:

       IPC_CREAT   to create a new segment. If this flag  is  not  used,  then
                   shmget()  will  find the segment associated with key, check
                   to see if the user has  permission  to  receive  the  shmid
                   associated  with the segment, and ensure the segment is not
                   marked for destruction.
                                                                                
       IPC_EXCL    used with  IPC_CREAT  to  ensure  failure  if  the  segment
                   exists.
                                                                                
       mode_flags (lowest 9 bits)
                   specifying the permissions granted to the owner, group, and
                   world.  Presently, the execute permissions are not used  by
                   the system.

It is quite reminiscent of "open" call, and while normal (ab)user can open /boot/bzImage file, he usually cannot write to it, unless he's super-(ab)user and not an ordinary one. It is the same story exactly with the shared memory segments. Potential benefits for the ordinary (ab)user like me comes from the fact that, using this, I might be able to read ASCII passwords stored somewhere in the SGA and become an (ab)user with the DBA & SYSDBA privilege, and much more entertaining as such. Of course, being a DBA, I already have all privileges, which means that the code is without value for me. If someone breaks into my database using this perversion, I'll look for the instigator and let him have a really bad Finnegan's wake.

-- 
Mladen Gogala
Oracle DBA



Note:
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Tue Jun 15 2004 - 14:25:12 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US