Remove panics for rename() race conditions. The panics are inappropriate

because the IN_RENAME flag only fixes a few of the huge number of race
conditions that can result in the source path becoming invalid even
prior to the VOP_RENAME() call.  The panics created a serious security
issue whereby an attacker could fairly easily cause the panic to
occur, crashing the machine.

The correct solution requires a great deal of work in the namei
path cache code.

MFC after:	0 days
This commit is contained in:
Matthew Dillon 2001-10-08 00:37:54 +00:00
parent 82ab7a3bc2
commit 962922dcd2
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=84642

View File

@ -1261,10 +1261,16 @@ ufs_rename(ap)
dp = VTOI(fdvp);
} else {
/*
* From name has disappeared.
* From name has disappeared. IN_RENAME is not sufficient
* to protect against directory races due to timing windows,
* so we have to remove the panic. XXX the only real way
* to solve this issue is at a much higher level. By the
* time we hit ufs_rename() it's too late.
*/
#if 0
if (doingdirectory)
panic("ufs_rename: lost dir entry");
#endif
vrele(ap->a_fvp);
return (0);
}
@ -1278,8 +1284,17 @@ ufs_rename(ap)
* by a rmdir.
*/
if (xp != ip) {
/*
* From name resolves to a different inode. IN_RENAME is
* not sufficient protection against timing window races
* so we can't panic here. XXX the only real way
* to solve this issue is at a much higher level. By the
* time we hit ufs_rename() it's too late.
*/
#if 0
if (doingdirectory)
panic("ufs_rename: lost dir entry");
#endif
} else {
/*
* If the source is a directory with a