Fix bug:rmdir could remove current working directory
PATCH 1/1 Fix bug:rmdir could remove current working directory
Hi Linus, Alan and Al,
I found that rmdir(2) could remove current working directory successfully. This happens when the given pathname points to current working directory, not ".", but something else. For example, the current working directory's absolute pathname. I read the man page of rmdir(2). It says in this case EBUSY error should be returned. I suspected this is a bug and added a check in vfs_rmdir(). The following patch is against 2.4.10 and has been verified. Please comment and apply.
Signature · 13 lines
Mingming Cao
--- linux-2.4.10/fs/namei.c Tue Sep 18 11:01:47 2001
+++ /home/ming/linux-tk/fs/namei.c Tue Oct 9 11:58:50 2001
@@ -1362,6 +1362,8 @@
error = -ENOENT;
else if (d_mountpoint(dentry))
error = -EBUSY;
+ else if (dentry == current->fs->pwd)
+ error = -EBUSY;
else {
lock_kernel();
error = dir->i_op->rmdir(dir, dentry);Quoted 10 lines · Mingming cao
Hi Linus, Alan and Al,
I found that rmdir(2) could remove current working directory successfully. This happens when the given pathname points to current working directory, not ".", but something else. For example, the current working directory's absolute pathname. I read the man page of rmdir(2). It says in this case EBUSY error should be returned. I suspected this is a bug and added a check in
vfs_rmdir(). The following patch is against 2.4.10 and has been verified. Please comment and apply.
It's not a bug. Moreover, test you add is obviously bogus - what about cwd of other processes?
Actually, rmdir() on a busy directory _is_ OK. Implementation is allowed to refuse doing that, but it's not required to.
Quoted 14 lines · Alexander Viro
Quoted 10 lines · Mingming cao
Hi Linus, Alan and Al,
I found that rmdir(2) could remove current working directory successfully. This happens when the given pathname points to current working directory, not ".", but something else. For example, the current working directory's absolute pathname. I read the man page of rmdir(2). It says in this case EBUSY error should be returned. I suspected this is a bug and added a check in
vfs_rmdir(). The following patch is against 2.4.10 and has been verified. Please comment and apply.
Quoted 5 lines
It's not a bug. Moreover, test you add is obviously bogus - what about cwd of other processes?
Actually,
rmdir()on a busy directory _is_ OK. Implementation is allowed to refuse doing that, but it's not required to.
I thought about the case when rmdir() on the cwd of other processes, but, as you said, that is implementation dependent. However rmdir() on "." does returns EBUSY error. Should not we keep the rmdir() behavior
consistent: rmdir() on the current working directory of the current process is not OK?
Signature · 1 line
Mingming Cao
Quoted 5 lines · Mingming cao
I thought about the case when
rmdir()on the cwd of other processes, but, as you said, that is implementation dependent. Howeverrmdir()on "." does returns EBUSY error. Should not we keep thermdir()behavior
consistent:rmdir()on the current working directory of the current process is not OK?
We do. It's not just ".", "foo/bar/." is also prohibited. IOW, the rule is "the last component of name should not be . or ..". Please, look through archives - it had been beaten to death many times.
In article <[email protected]>,
Quoted 4 lines · Mingming cao
I thought about the case when
rmdir()on the cwd of other processes, but, as you said, that is implementation dependent. Howeverrmdir()on "." does returns EBUSY error.
That's a completely different thing, though - even though the difference is rather subtle.
You can remove pretty much any empty directory (if the filesystem permits it - some don't). HOWEVER, you can not use "." as the final component of your pathname.
It has nothing to do with home directory: you can try just doing
mkdir /tmp/hello
rmdir /tmp/hello/.
and you'll get the same error (and it _should_ return EINVAL, not EBUSY. EBUSY is for the "this filesystem doesn't allow you to remove a directory that is in use" case).
Linus
Quoted 17 lines · Linus Torvalds
In article <[email protected]>,
Quoted 4 lines · Mingming cao
I thought about the case when
rmdir()on the cwd of other processes, but, as you said, that is implementation dependent. Howeverrmdir()on "." does returns EBUSY error.That's a completely different thing, though - even though the difference is rather subtle.
You can remove pretty much any empty directory (if the filesystem permits it - some don't). HOWEVER, you can not use "." as the final component of your pathname.
It has nothing to do with home directory: you can try just doing
Quoted 8 lines
mkdir
/tmp/hello
rmdir/tmp/hello/.and you'll get the same error (and it _should_ return EINVAL, not EBUSY. EBUSY is for the "this filesystem doesn't allow you to remove a directory that is in use" case).
Linus
I misunderstanded the rule. Thanks for clarifying!
Signature · 1 line
Mingming Cao
Quoted 5 lines · Mingming cao
I read the man page of
rmdir(2). It says in this case EBUSY error should be returned. I suspected this is a bug and added a check invfs_rmdir(). The following patch is against 2.4.10 and has been verified. Please comment and apply.
The bug is in the manpage. This was discussed over a year ago (some time after 2.1.44 introduced dcache (it was broken then, but that's when it appeared.))
--Ricky
Quoted 8 lines · Ricky Beam
Quoted 5 lines · Mingming cao
I read the man page of
rmdir(2). It says in this case EBUSY error should be returned. I suspected this is a bug and added a check invfs_rmdir(). The following patch is against 2.4.10 and has been verified. Please comment and apply.The bug is in the manpage. This was discussed over a year ago (some time
Well, the manpage only states what certain error nr. returns may mean, not what will be returned when. Do you have an improvement on :
EBUSY pathname is the current working directory or root directory of some process.
regards
john
Signature · 3 lines
"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth