Date: Tue, 06 Sep 2005 11:29:19 -0500 (CDT) From: Sergey Babkin <babkin@verizon.net> To: Giorgos Keramidas <keramida@freebsd.org>, Igor Shmukler <shmukler@mail.ru> Cc: Dag-Erling Sm?rgrav <des@des.no>, Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru>, freebsd-hackers@freebsd.org Subject: Re: Re: vn_fullpath() again Message-ID: <11338458.1126024159573.JavaMail.root@vms171.mailsrvcs.net>
next in thread | raw e-mail | index | archive | help
>From: Giorgos Keramidas <keramida@freebsd.org> >On 2005-09-06 19:27, Igor Shmukler <shmukler@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11338458.1126024159573.JavaMail.root>