linux-kernel - Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries

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:	Sun, 08 Jul 2012 02:00:13 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	"Steven J. Magnani" <steve@...idescorp.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries

"Steven J. Magnani" <steve@...idescorp.com> writes:

>> You mean the unhashed inode is created by ->get_parent()? If so, the
>> root cause sounds like ->get_parent() itself. If not, I'm not
>> understanding the meaning of the temporary/unofficial inode here.
>
> Maybe "private" is a better word than "unofficial". Private inodes are
> created anywhere fat_new_inode (nee fat_build_unhashed_inode) is called
> directly, instead of through fat_build_inode. So yes, this is on the
> get_parent paths (via fat_lookup_dir), and also on the fh_to_dentry path
> when inode reconstruction is necessary.
>
> With private inodes, I don't see how anyone but the code that created
> them could find them to lock them. The reason they're private is that
> they're temporary aliases; at the time they're created, we don't have
> enough information to register them in a way that others could find
> them. A lookup, etc. operation will look for the inode of the "drivers"
> directory, not the ".." of the "usb" directory. We do need these private
> inodes in order to walk directory entries. I don't think they're a
> problem that needs solving; if we didn't use private inodes, we'd still
> need a way to walk directory entries in the context of these NFS
> operations, and there would still be potential races between that and
> other operations on the filesystem.

How do you prevent to modify or free the those inode/blocks from other
path?  Yeah, it is racy. And if races is not solved, that's simply wrong
and not solution.

Although I'm not thinking deeply about NFS support on FAT. Just a idea,
the one of possible solutions would be register it to hash, and find it
on all path. So, all path will use same inode and lock.

We need the key, possible key is - if it is only directory, FAT may be
able to use i_start as additional search key.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/