X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-497860.5 required=5.0 tests=AWL,BAYES_00
X-Spam-Check-By:	sourceware.org
X-MDAV-Processed:	mail1.multiplay.co.uk, Tue, 01 Dec 2009 19:38:02 +0000
X-Spam-Processed:	mail1.multiplay.co.uk, Tue, 01 Dec 2009 19:38:00 +0000 (not processed: message from trusted or authenticated source)
X-MDRemoteIP:	213.123.247.160
X-Return-Path:	prvs=158624c46c=killing AT multiplay DOT co DOT uk
X-Envelope-From:	killing AT multiplay DOT co DOT uk
X-MDaemon-Deliver-To:	cygwin AT cygwin DOT com
Message-ID:	<DF320CC31CF9494CB069ED1CEA82293F@multiplay.co.uk>
From:	"Steven Hartland" <killing AT multiplay DOT co DOT uk>
To:	<cygwin AT cygwin DOT com>
References:	<BE3716D1FE6B45B6A50DEB1B448E71ED AT multiplay DOT co DOT uk> <4B12FB72 DOT 9090206 AT x-ray DOT at> <270B141F0B5B480C9A668369AA2C53A3 AT liv3dworkpc> <5E63D05B501C4339A7D7F8909505E828 AT multiplay DOT co DOT uk> <4B15556A DOT 4080108 AT gmail DOT com> <20091201173036 DOT GE8059 AT calimero DOT vinschen DOT de> <30397F695F2C4913B332511F9A2E839A AT multiplay DOT co DOT uk> <20091201181336 DOT GG8059 AT calimero DOT vinschen DOT de>
Subject:	Re: Nasty permissions / pathing bug on 1.7
Date:	Tue, 1 Dec 2009 19:37:42 -0000
MIME-Version:	1.0
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

----- Original Message ----- 
From: "Corinna Vinschen"

> Win32 path -> No POSIX path -> no POSIX permissions.

So then why does it have any permissions support at all? By allowing
permissions to be read and obeyed, but not written, your sending out
very much mixed messaging which is confusing at best and dangerous
to the user at worst.

A simple example is that process creation using the Win32 perl module
under cygwin taking win32 paths fails when the execute permission set
on the target binary is not set. This is the case which highlighted
the problem to us.

> There was a thread on this list about this very problem a couple of
> months ago.  It was generally agreed that handling Win32 paths this way
> consistently is a good thing.

I would like to challenge this, as its unituitve, undocumented ( as far
as I can see ) and very confusing for the user see above and below.

>> 2. Surely when performing changes on permissions with a mount mode of
>> noacl it should be a fatal error?
> 
> No.  "noacl" means that permissions are faked.
> 
> It's easy.  If you want POSIX permssion handling, stick to the POSIX
> world.

That's easy to say but surely the entire goal of cygwin is to ease
the interaction of Windows and POSIX functionality is it not? While I
appreciate change is often required to make progress, it seems quite clear
that this change in behaviour in its current state is very much a disaster
waiting to happen or some users.

Why do I say that? Well first off from our experience this was an
nightmare to track down, taking several days to identify the source of
this quite random behaviour. Now if your think about the number of
scripts, binaries etc which may also be broken by this change but not
know about it; surely that's not something you want to inflict on the
cygwin user base is it?

To be clear, my objection to this is not that it's been changed, although
IMO doing so to be consistent doesn't seem like a very compelling reason
given other aspects don't abide by the same rules; its that the change
silently breaks things! Surely no one thinks that's an expectable state
of play do they?

To conclude, we've already changed our code in this particular example
to workaround this issue and we're aware of it for the future, but how
many others are going to get burnt and waste significant amounts of time
tracking down issues created by this change if it remains in its current
state?

Given this I would respectfully like to propose either:-
1. Warn but preferably error when performing set permission operations
on noacl mount points.
2. Revert so that Win32 paths aren't mounted with noacl.

#1 with an error would be my personal preference. It would have allowed
us to identify and correct this issue in seconds instead of the days it
actually took.

    Regards
    Steve


--
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

- Raw text -