Thanks George. That seems to be the case. Hope we can sell that to our auditors. On Tue, Jul 21, 2009 at 2:08 AM, Johnson, George <George.Johnson@xxxxxxx>wrote: > 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:2318668671089 >>> . >>> 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. >