Without going into why I'm interested or why it would be important enough to
be to bring it up on the mailing list, I noticed that in namei.c, the
functions may_create and may_destroy are called in turn by vfs_rename_*(). I
presume the argument for it being this way is that while the actual object is
not created or destroyed, the links to the object in the directory may be
destroyed. Is the inability to rename one's own file when in a directory with
no write permissions something that's required by POSIX? It seems to be pretty
standard, although it seems symantically incorrect to make calls named destroy
and create.
Besides that, I notice that if the target object already exists, the ability
to delete it is checked, but not the ability to create the new object. I
suppose the argument is since there was something in the directory before, and
something of that same name will still be there, that only file checks, and
not parent directory checks should be made. But if create isn't called, then
why should destroy?
Thanks
-
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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:16 EST