linux-kernel - Re: [RFC PATCH 0/2] Union Mount: Directory listing in glibc

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]

Message-ID: <20080429160431.GY30780@bolzano.suse.de>
Date:	Tue, 29 Apr 2008 18:04:31 +0200
From:	Jan Blunck <jblunck@...e.de>
To:	bsn.0007@...il.com
Cc:	libc-alpha@...rceware.org, Erez Zadok <ezk@...sunysb.edu>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	viro@...iv.linux.org.uk, Christoph Hellwig <hch@....de>,
	Ulrich Drepper <drepper@...hat.com>,
	Mingming Cao <cmm@...ibm.com>,
	Dave Hansen <haveblue@...ibm.com>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	bharata@...ux.vnet.ibm.com, David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC PATCH 0/2] Union Mount: Directory listing in glibc

On Tue, Apr 29, bsn.0007@...il.com wrote:

> The RFC discussed about the information glibc readdir needs to get about
> union mounted directories and I have assumed the following information
> to be available from the kernel for this implementation.
> 
> - Kernel would return all the dirents (including duplicates and whiteouts)
> starting from the topmost directory of the union.
> 
> - Indication that this directory is a union mounted directory
> 	I have assumed that kernel would return a "." whiteout as the first
> directory entry of the union. This would tell glibc readdir(3) that it is
> working with a union mounted directory and it needs to do duplicate
> elimination and whiteout suppression. It starts building a dirent cache
> for this purpose.

IIRC the intention was to emit a "." whiteout when "changing" from one
directory to the next. That means when the first directory is completely read
the whiteout is emitted. After that glibc knows to start duplicate
removal.

> Ulrich had suggested that we could use the fstat call to recognize union
> mounts. But looking at the stat structure from stat(2), it was not obvious
> as to which field in there could be used for this purpose. Hence for this
> prototype implementation, I decided to go with what Al Viro suggested, which
> is about using a "." whiteout.
> 
> - Indication that kernel is done with returning entries from the topmost
> directory.
> 	I have assumed that kernel would return a "." whiteout at the beginning
> of each directory of the union. So when glibc gets a 2nd "." whiteout, it
> will start performing duplicate elimination.

See above

> - Whiteout indication
> 	glibc will depend on dirent->d_type to be set to DT_WHT on a whiteout
> file.

Which makes the new filetype very much visible to the userspace but maybe that
is the price we have to pay.

> Compatibility issues
> --------------------
> There are many versions of dirent structure in glibc and I have tried my
> best to take care of compatibility issues. But I have not really tested
> readdir64 or old_readdir64. Also atleast one version of dirent structure
> doesn't have d_type field and my whiteout suppression logic depends on it
> and uses it in the generic __READDIR routine which gets used by various
> version of readdir and I think this would break that readdir version which
> uses dirent structure w/o d_type. I will be taking care of such compatibility
> issues more cleanly/thoroughly in subsequent posts.

We don't support union mounts on older kernels. Newer kernels return
d_type. So I think we don't have a problem.

Regards,
	Jan

-- 
Jan Blunck <jblunck@...e.de>
--
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/