On Wed, 02 Jun 2010, Szak�ts Viktor wrote: Hi Viktor and Tamas,
The security problem with links appears when any file is open for writing and previous contents of the file is not released so application cannot use 'unlink' and O_EXCL flag (or workarond with 'link' for race condition in old NFS <= 3.0 protocols). BTW for security reasons we should have such code The idea with copping the file original file body to new one when log is created does not resolve the problem but replace it with the new one even worser, i.e.: ln -s /ets/shadow /tmp/hb_out.log and I can read encrypted passwords for brutal force attack. Of course any soft links can be eliminated by using O_NOFOLLOW open() flag on systems which support it but it does not help for hard links so the problem still exists (good admins used to keep vital system files on separate partitions without any write access for users so they cannot create any hard links) but we can try to make farther protection and use fstat() to check number of links. It's still not perfect because we have race condition which cracker may try to exploit but if we can compare fstat() results with stat() results to be sure we are talking about the same file. It's efficient solution for systems which supports O_NOFOLLOW but this is not POSIX flag and some older *nixes may not have it. If you want then I can add such protection. All programs opening/creating files have such problems and it's programmer job to create application protected against such attack, i.e. my production applications drop root privileges switching to some other user and group ID. In this particular case we are talking about hb_out.log files created when harbour application crashes so it's not sth what should appear in production code but it cannot be excluded. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
