vn_fullpath() again

[Sergey Babkin]

>From: Giorgos Keramidas <keramida at freebsd.org>

>On 2005-09-06 19:27, Igor Shmukler <shmukler at mail.ru> wrote:
>> Perhaps, I do not get it or maybe you are do not getting my point.
>>
>> There are times when resolving would not be possible or a name returned is
>> not necessarily the one used when file was first accessed. We have discussed
>> it here and everyone agreed on that. The hardlinks or files unlinked while
>> vnode is still open are corner cases. The unlink is a bit more difficult to
>> deal with, but hardlinks are probably not a big issue. As long as we can get
>> A name, we may not even need to know THE name.
>
>Why does it make sense to get name A in the following scenario then?
>
>	user 1 creates file A
>	user 1 hardlinks this to B
>	user 1 gets the "real name" of A
>	user 2 deletes file A
>	user 2 creates a new file called A
>	user 1 tries to access A and gets something unexpected
>
>Corner cases and their handling *is* important.  Find another way to do
>whatever it is you're thinking you can do with "the real name of a vnode".

This particular case is easy to handle: all that user 1
needs to do is to do fstat() after opening the
file and check that the returned inode field is still
the same.

On the otehr hand, if there is this new interface to
access files directly by inode numbers, why bother
with any names at all? If a name is so desirable, then
just create a pseudo-fs translation that would
convert the text-formatted device and inode number given to
it as a file name to an access to the identified file.

Though both this and access directly by vnode number
open a security hole: in many cases the access to files
mught be actually limited by making the directories
unreadable to the unwanted users. Bypassing the
directories bypasses this "security by obscurity".

-SB