> Alexander Viro <viro@math.psu.edu> writes:
>
> |> --- fs/namei.c Tue Feb 9 10:17:15 1999
> |> +++ fs/namei.c.new Fri Feb 12 07:46:04 1999
> |> @@ -942,6 +942,9 @@
> |> if (error)
> |> return error;
> |>
> |> + if (dentry == current->fs->pwd)
> |> + return -EINVAL;
> |> +
> |> if (!dir->i_op || !dir->i_op->rmdir)
> |> return -EPERM;
>
> This patch is wrong, it also forbids `rmdir ../foo'. Only a path ending
> in '.' is special. Think about it: to find out the real name of the entry
> to unlink you'll have find its link in the parent directory. With `.' you
> simply don't have enough information about what to unlink.
Erm??? SunOS 5.6 (both on tmpfs and NFS) doesn't allow "../foo"
just as it doesn't allow ".". And yes, it does allow rmdir of busy
directory. Looking at the 4.4BSD code it seems that they have the same
behaviour (I'm not on *BSD box right now).
> |> Linus, could you apply this patch? IMHO it makes sense - it
> |> explicitly forbids rmdir of one's pwd.
>
> That doesn't make sense at all. The current process's pwd is in no way
> special.
Hmm... Fine. In this case we'll need to mess with lookup() -
after it there is no trace of . in the name. That is, one more flag to
pass... Arrghhh... Linus, would you mind switching to nameidata mechanism?
That is, instead of (OK, in addition to) namei() and friends the following
thing:
a) initialize the structure describing lookup request (name, flags a-la
lookup/create/remove, follow, etc., root dentry, current dentry) with a
macro
b) pass it to new_namei().
It looks like the right thing anyway (e.g. completely iterative
symlink resolution) and amount of flags already looks messy. I can roll
such patch - it doesn't break anything that still uses old mechanism and
it's fairly trivial to write. BTW, it would be able to do final-step
checks (sticky, etc. - current may_delete()/may_create() stuff).
If it comes to the need of special parsing on the last step - why
not tell to poor thing what we want to do with dentry it will give us?
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/