RE: datafile permissions

  • From: "Reidy, Ron" <Ron.Reidy@xxxxxxxxxxxxxxxxxx>
  • To: <all_about_oracle@xxxxxxxxxx>, "Khemmanivanh, Somckit" <somckit.khemmanivanh@xxxxxxxxxxxxxxxx>, <raja4list@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 6 Jul 2005 05:46:36 -0600

So, to test it out, change the C program to perform more writes.  Run it in the 
debugger and during the writes, chmod 000.  What happens?

-----Original Message-----
From:   oracle-l-bounce@xxxxxxxxxxxxx on behalf of Sinardy
Sent:   Tue 7/5/2005 11:45 PM
To:     Khemmanivanh, Somckit; raja4list@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject:        Re: datafile permissions
Your test is good, just if you "accidentally" chmod 000 *.dbf during online and 
batch job is still running what will happen to the db? 
This is what I believe his manager try to prevent.
Anyway technically you are right.

  ----- Original Message ----- 
  From: Khemmanivanh, Somckit 
  To: all_about_oracle@xxxxxxxxxx ; raja4list@xxxxxxxxx ; 
  Sent: Wednesday, July 06, 2005 1:30 PM
  Subject: RE: datafile permissions

  Not to harp on this too much but I'm really failing to see how this is such a 
risky task? He's going from mode 600 to 640.

  You can run this test yourself to see that there shouldn't be any issues with 
doing this.

  1) create a test file
  rm skf
  touch skf
  chmod 600 skf
  ll skf
  -rw-------     0 Jul  5 22:16 skf

  2) As a control run the supplied C program I whipped up to test. All it does 
is open the file and write a bunch text to it

  It will create a file exactly 99999999 bytes in size

  ll skf
  -rw-------        99999999 Jul  5 22:17 skf

  Below is the code (compile and run it)

  #include <stdio.h>
  int main ()
    FILE * myf;
    int counter = 0;

    myf = fopen ("skf","wt");
    if (myf != NULL)
       while ( counter < 99999999)
        fputs ("t", myf);

  3) Delete the skf file and recreate it with mode 600 for the run with the 
chmod in it.
  --Run the program in 1 session and in another session run the following 

  ll skf; chmod 640 skf; ll skf
  -rw-------       6062080 Jul  5 22:18 skf
  ^^^--Note the mode is 600 from the first ll skf commnd

  -rw-r-----        6193152 Jul  5 22:18 skf
  ^^^--Note the mode has changed to 640 with the chmod comand (this while the 
other program is still writing to the file)

  4) Now recheck the file after it's all complete.
  ll skf
  -rw-r-----        99999999 Jul  5 22:19 skf

  Does anyone see any flaws with this test???

  From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Sinardy
  Sent: Tuesday, July 05, 2005 9:31 PM
  To: raja4list@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
  Subject: Re: datafile permissions

  If someone is writing to the file then you revoke the access using OS command 
which is it can be done with Unix I believe your manager forsee this will 
corrupt the datafile.

  Anyway, if I am asked to perform such harderning change, I will request for 
down time. For may be 1 hour, stop applications, shutdown, chmod, startup, 
switch log file, test, star application. not only datafile offline.

  PS: I know that 640 should be ok but chmod during online is quite a risky 

    ----- Original Message ----- 
    From: raja rao 
    To: oracle-l@xxxxxxxxxxxxx 
    Sent: Wednesday, July 06, 2005 5:19 AM
    Subject: datafile permissions

    Hi All,

    Sun OS 2.9 
    oracle 9i

    In what state the datafiles should be when i want to change the OS file 
    from 600 to 640 

    chmod 640 *.dbf

    I put the tablespace offline.  is that enough?, or should i make the 
datafiles offline withi

    alter database datafile 'filename' offline;

    I had a fight with my manager. He asked me to put the datafiles offline 
using alter database.
    But Just i put the tablespace offline and did that. Just want to make sure 
what is
    the right way (precautiion to be taken) for this task ?

    Thanks in advance,
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around 

This electronic message transmission is a PRIVATE communication which contains
information which may be confidential or privileged. The information is 
to be for the use of the individual or entity named above. If you are not the 
intended recipient, please be aware that any disclosure, copying, distribution 
or use of the contents of this information is prohibited. Please notify the
sender  of the delivery error by replying to this message, or notify us by
telephone (877-633-2436, ext. 0), and then delete it from your system.


Other related posts: