DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:mime-version
	:content-type; q=dns; s=default; b=eXn2spkPOdHsgcX0tuP48ufaubwgt
	vwO+M4BKaeOlGzc9jJpO5WyRI+f2QTFtGJy2EcyV/n/8NwkHs07SaBfD4uIbUt78
	ydKIq5EQMYfFZuoqTW4yEp8Oa2PdDxV2ok08gVytkemgkZmZyFSIKwFm+tKUEByu
	cIb/WLKQjrukKw=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 10 Dec 2014 17:27:06 +0000
From: Zefram <zefram AT fysh DOT org>
To: cygwin AT cygwin DOT com
Subject: openat fakery is misleading
Message-ID: <20141210172706.GA28347@fysh.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Cygwin offers openat(2) et al functions, which superficially appear
to work, but actually they're fake implementations that use absolute
pathnames underneath.  This means that they fail in ways that real
openat(2) et al cannot fail, as soon as any relevant renaming occurs.
This misleads programs into thinking they're getting proper referential
semantics, thus breaking any that rely on it.

I've run into this in the context of a Perl module that I wrote,
Hash::SharedMem, which uses openat(2) et al if they're available.
Fortunately I'm paranoid enough that the test suite actually checks
the behaviour across renaming, leading to the tests failing on Cygwin,
avoiding installing a broken module:

http://www.cpantesters.org/cpan/report/cecb2802-6dbc-1014-8ea7-f699f03158fb

By the way, thanks very much for making mmap and all that other Unixy
goodness work.  This module relies heavily on Unix semantics for file
operations and especially memory mapping.

I found an archived mail message describing the implementation of the
faked openat(2) et al:

http://www.cygwin.com/ml/cygwin-developers/2008-04/msg00108.html

She comments that "having these functions in is better than not".
I profoundly disagree.  Faking openat(2) is sometimes acceptable,
depending on the application.  It's acceptable for Hash::SharedMem, which
contains code to perform such fakery.  But the fundamental differences
in behaviour between fd-based and name-based directory references
mean that in general the application needs to know which it's getting.
(Hash::SharedMem advertises which way it's working to its caller, which
can make an informed decision about whether name-based references are
acceptable for its purposes.)  It's very rude to foist fake directory
references on an unwilling application, and just asking for trouble to
do so under the semblance of a promise of real referential integrity.

Providing a faked openat(2) is far worse than providing no openat(2)
at all.  As long as these functions cannot be implemented in a way that
exhibits the distinctive behaviour of the real thing, they should either
be unavailable at compile time or consistently signal ENOSYS at runtime.

-zefram

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple