It's simple to prove. ls -l pwdfile change a password ls -l pwdfile The timestamp will change Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist On Tue, Jul 21, 2009 at 9:29 AM, Ram Raman <veeeraman@xxxxxxxxx> wrote: > 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. >> > >