linux-kernel - Re: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Dec 2008 18:08:08 -0500
From:	"C. Scott Ananian" <cscott@...top.org>
To:	"Al Viro" <viro@...iv.linux.org.uk>
Cc:	"Eric Paris" <eparis@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify

On Mon, Dec 22, 2008 at 4:04 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Mon, Dec 22, 2008 at 02:59:37PM -0500, C. Scott Ananian wrote:
>> > 2) major vfs and every FS redesign me thinks.
>>
>> I'm not convinced of that.  I'm pretty certain one could export
>> symlinks /proc/<pid>/mountinfo/<dev>/<inode> -> <absolute path in
>> processes' namespace> with very little trouble, and no violence done
>> to the VFS, which already has an iget() function which does the heavy
>> lifting.
>
> There is no such thing as absolute path of inode *anywhere*, process
> namespace or not.  Not on any UNIX.  Period.  End of story.

That's not correct, as /proc/self/fd/<num> and the getcwd syscall make
clear.  struct inode has a i_dentry member, and via its d_parent links
you can reconstruct the path, as __d_path in fs/dcache.c does.

Of course, this only works as long as the inode is in the kernel's
cache (which implies all the appropriate dentry items are there, too).
 For an open file descriptor, this works well.  If you index the open
file now and then return sometime later to try to open it, there's no
guarantee.

If the inode represents a directory, we *could* use the magic '..' and
'.' entries to reconstruct its path, even without its being in the
cache.  I haven't looked hard, but that might involve VFS violence.
But having to manually track what directory inode a given file was in
is still an improvement over having to duplicate the entire directory
tree.

We can also debate whether finding *a* name for the inode if
sufficient, or if you really need to know *all* names for the inode.
One is plenty if you're just looking for a path to give on the command
line to (say) emacs to open the file after a successful search.  But
then emacs may not be happy when it tries to write a backup file to an
arbitrarily chosen directory.

> Al, once again astonished by the ability of desktop developers to post from the alternative realities they apparently inhabit...

I think you're prejudging.  I'm certainly posting from a weird twisted
alternate reality, but by and large it's not the "desktop developer"
one. ;-)

There are a paucity of good solutions.  We can follow the example of
old-school UNIX dump and open the filesystem's block device directly
to map inodes to paths.  Or we can use 'find' over the entire
filesystem.  Or we can duplicate the filesystem's directory structure
in userspace so that we can correctly associate index information with
the current path to the given file?

inotify *almost* lets us do that last thing (though the code
duplication pains me) but is too racy for reliable use. Give me a
kernel interface without races and I'll call it a good start.  If you
can save me the trouble of duplicating all of the filesystem's
directory information in my userspace database in order to handle
directory moves, I'll actually grin a little.
 --scott

-- 
                         ( http://cscott.net/ )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/