RE: Password file timestamp

  • From: "Johnson, George" <George.Johnson@xxxxxxx>
  • To: <veeeraman@xxxxxxxxx>, "Jared Still" <jkstill@xxxxxxxxx>
  • Date: Tue, 21 Jul 2009 08:08:06 +0100

I have noticed under our Solaris versions 9205, 10 and 11 that if
you change the password of any user, irrespective of SYSDBA grant or
not, the password file gets "touched" and the file timestamp is updated.
I have only observed this on our systems and my Linux test box. Creation
of user doesn't seem to trigger it, but subsequently changing the
password does, even if the user has no grants at all, not even create
session.
 
Here's a sample from a 10.2.0.3:
 
 
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi

SQL> select name from v$database;
 
NAME
---------
LDND2
 
SQL> !ls -ltr orapwLDND2
-rw-r-----   1 oracle   dba         3584 Jul 21 08:02 orapwLDND2
 
SQL> select to_char(sysdate, 'dd-mon-yyyy hh24:mi') from dual;
 
TO_CHAR(SYSDATE,'
-----------------
21-jul-2009 08:04
 
SQL> create user gxj3 identified by fred;
 
User created.
 
SQL> select * from v$pwfile_users where username = 'GXJ3';
 
no rows selected

SQL> !ls -ltr orapwLDND2
-rw-r-----   1 oracle   dba         3584 Jul 21 08:02 orapwLDND2
 
SQL> alter user gxj3 identified by fred;
 
User altered.
 
SQL> select to_char(sysdate, 'dd-mon-yyyy hh24:mi') from dual;
 
TO_CHAR(SYSDATE,'
-----------------
21-jul-2009 08:04
 
SQL> !ls -ltr orapwLDND2
-rw-r-----   1 oracle   dba         3584 Jul 21 08:04 orapwLDND2
 
 
    Rgds

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ram Raman
Sent: 21 July 2009 03:00
To: Jared Still
Cc: ORACLE-L
Subject: Re: Password file timestamp


Thanks Jared. 
 
We do not execute those commands. It still has changes to the files.
This happens with most prodcution databases. I realize that password
file has information about sysdba users, entries and the password. 


On Mon, Jul 20, 2009 at 7:34 PM, Jared Still <jkstill@xxxxxxxxx> wrote:


        GRANT|REVOKE SYSDBA|SYSOPER to <USER> would do it. 

        Jared Still
        Certifiable Oracle DBA and Part Time Perl Evangelist
        
        
        
        
        On Mon, Jul 20, 2009 at 4:47 PM, Ram Raman <veeeraman@xxxxxxxxx>
wrote:
        

                 
                Listers,
                 
                We have auditing enabled via a third party software and
one of the things they are auditing is $OH/dbs/passwordfiles. The
password files seem to get updated and it shows up in the audit reports.

                 
                I am trying to research on what is causing it, but have
been unsuccessful. I came across this one, which does not seem to answer
the question:
http://asktom.oracle.com/pls/asktom/f/f?p=100:11:0::::P11_QUESTION_ID:23
18668671089.
                I tried creating a test user and locking and unlocking
that user, but the password file timestamp did not change in the test
case. I tried a user with DBA privs, that did not change it either.
                 
                Anyone knows what causes the update of the password
files when we dont change the passwords.  
                 
                Version is 10.2.
                 
                
                Ram.
 
 Please consider the environment before printing
********************************************************************************************
This message contains confidential information and is intended only for the 
individual or entity named. If you are not the named addressee you should not 
disseminate, distribute or copy this email.
Please notify the sender immediately by e-mail if you have received this e-mail 
by mistake and delete this e-mail from your system. E-mail transmission cannot 
be guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission. If 
verification is required please request a hard-copy version. This message is 
provided for informational purposes and should not be construed as an 
invitation or offer to buy or sell any securities or related financial 
instruments. GAM operates in many jurisdictions and is regulated or licensed in 
those jurisdictions as required.
To the extent this email has been sent to you by any GAM company domiciled in 
the EU, being GAM (U.K.) Limited, GAM Sterling Management Limited, GAM 
International Management Limited, GAM London Limited, GAM Fund Management 
Limited, or GAM Fonds Marketing GmbH i.L., please note the following details in 
respect of each such company: - GAM (U.K.) Limited (a company limited by shares 
and registered in England and Wales with company number 01664573); - GAM 
Sterling Management Limited (a company limited by shares and registered in 
England and Wales with company number 01750352); - GAM International Management 
Limited (a company limited by shares and registered in England and Wales with 
company number 01802911); - GAM London Limited (a company limited by shares and 
registered in England and Wales with company number with Company Number 
00874802) Each of Registered Office: 12 St. James's Place, London, SW1A 1NX
GAM Sterling Management Limited, GAM International Management Limited and GAM 
London Limited are each authorised and regulated by the Financial Services 
Authority. GAM Fund Management Limited (a company limited by shares and 
registered in Ireland with no. 156828) of Registered Office: George's Court 
54-62 Townsend Street Dublin 2, Ireland 
GAM Fonds Marketing GmbH, i.L. (a company limited by shares and registered in 
Germany under No. HRB 66857) of Friedrichstrasse 154, D-10117 Berlin, Germany. 
The competent Commercial Register is "Amtsgericht Charlottenburg" in Berlin. 
Liquidator: Daniel Durrer.

Other related posts: