linux-kernel - Re: [PATCH 13/35] fallthru: ext2 fallthru support

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 for Android: free password hash cracker in your pocket

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

Message-Id: <E1O4WKa-0003Pp-0y@pomaz-ex.szeredi.hu>
Date:	Wed, 21 Apr 2010 11:34:52 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Jamie Lokier <jamie@...reable.org>
CC:	jblunck@...e.de, miklos@...redi.hu, vaurora@...hat.com,
	dwmw2@...radead.org, viro@...iv.linux.org.uk,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 13/35] fallthru: ext2 fallthru support

On Wed, 21 Apr 2010, Jamie Lokier wrote:
> Hmm.  I smell potential confusion for some otherwise POSIX-friendly
> userspaces.
> 
> When I open /path/to/foo, call fstat (st_dev=2, st_ino=5678), and then
> keep the file open, then later do a readdir which includes foo
> (dir.st_dev=1, d_ino=1234), I'm going to immediately assume a rename
> or unlink happened, close the file, abort streaming from it, refresh
> the GUI windows, refresh application caches for that name entry, etc.
> 
> Because in the POSIX world I think open files have stable inode
> numbers (as long as they are open), and I don't think that an open
> file can have it's name's d_ino not match the inode number unless it's
> a mount point, which my program would know about.
> 
> This plays into inotify, where you have to know if you are monitoring
> every directory that contains a link to a file, to know if you need to
> monitor the file itself directly instead.
> 
> Now I think it's fair enough that a union mount doesn't play all the
> traditional rules :-)  C'est la vie.
> 
> This mismatch of (dir.st_dev,d_ino) and st_ino strongly resembles a
> file-bind-mount.  Like bind mounts, it's quite annoying for programs
> that like to assume they've seen all of a file's links when they've
> seen i_nlink of them.
> 
> Bind mounts can be detected by looking in /proc/mounts.  st_dev
> changing doesn't work because it can be a binding of the same
> filesystem.
> 
> How would I go about detecting when a union mount's directory entry
> has similar behaviour, without calling stat() on each entry?  Is it
> just a matter of recognising a particular filesystem name in
> /proc/mounts, or something more?

Detecting mount points is best done by comparing st_dev for the parent
directory with st_dev of the child.  This is much simpler than parsing
/proc/mounts and will work for bind mounts as well as union mounts.

I think there's no question that union mounts might break apps (POSIX
or not).  But I think there's hope that they are few and can easily be
fixed.

Thanks,
Miklos
--
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/