MIME-Version: 1.0
Message-ID: <3332ee1c-fb85-4c4c-9dc0-8f2e2435aba3@default>
Date: Fri, 26 Sep 2014 09:59:13 -0700 (PDT)
From: Tsu-Phong Wu <tsu-phong.wu@oracle.com>
To: <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #8020] rename() failure in src/util/profile/prof_file.c:write_data_to_file()
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
RT-Send-Cc: 
Content-Length: 1879

> Under what circumstances does the rename fail after the hard link succeeds?

I think it happens this way,

  Process A opened krb5.conf for normal operation (krb5.conf opened)

  An UI could trigger profile update write_data_to_profile()
    created new krb5.conf.$$$
    deleted krb5.conf.bak
    link(krb5.conf, krb5.conf.bak)
    rename(krb5.conf.$$$, krb5.conf)
      rename() failed as krb5.conf was open
    so write_data_to_profile() failed and 
      left the extra "link" on krb5.conf and krb5.conf.$$$

  Process A finished and closed krb5.conf.

  Process A can no longer open krb5.conf due to the link count > 1

  Next profile update would cleaned up the above mess and
    process A can open krb5.conf again.

Above scenario can happen anytime and last for however long until next profile update.

In one recent scenario there were "Too many links" messages in our log spanning a 7 months period starting Dec 2013.
 
> What is the reasoning for using O_NOLINKS when reading krb5.conf?  (If you 
> can determine the reasoning; I realize that it might be an old change.)

O_NOLINKS and O_NOFOLLOW were introduced in a new API in 2000 in order to prevent redirecting to the wrong file via hard or symbolic links.

> It seems that even with the proposed change, there will always be a short 
> window where an open with O_NOLINKS will fail while a profile file is being 
> updated.  So there will still be a reliability issue associated with using 
> O_NOLINKS.  To remove that issue, we would have to eliminate the backup 
> file or create it using a copy operation.

We are always trying to get it more reliable, so we can either shorten the window or eliminate the window with more changed lines.

Thanks.
Tsu-Phong

> ______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs