X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 1 Dec 2009 22:07:52 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Nasty permissions / pathing bug on 1.7
Message-ID: <20091201210752.GK8059@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-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>  <DF320CC31CF9494CB069ED1CEA82293F AT multiplay DOT co DOT uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DF320CC31CF9494CB069ED1CEA82293F@multiplay.co.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Dec  1 19:37, Steven Hartland wrote:
> 
> ----- 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.

You can set the DOS R/O flag using chmod in this case.  All other
permissions are no permissions at all (FAT) or default Windows
permissions, inherited from the parent directories.

And chmod is working this way for ages.  Actually, way back in the mist
of times, switching the DOS R/O flag was all the chmod function could do.

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

Windows default is to set the execute bit for all files.  Your scenario
is puzzeling.  If you created the files using Cygwin functions/tools,
then why does the binary not have execute permissions?  Why didn't you
call chmod using POSIX paths?  If you created the binary using native
Win32 functions/tools, then why is it not executable by default?  And
why do you call chmod then, rather than SetSecurityInfo?  You're mixing
two worlds and are surprised that it leads to unexpected results?

And you never saw the "MS-DOS style path detected" message?

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

Windows paths are going along with Windows default behaviour quite
naturally.  Expecting POSIX behaviour when using Windows paths is
somewhat strange and *that* is unintuitive.

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

Maybe not the way you expect it.  Other users disagree since they expect
that Win32 paths behave the Win32 way.  They complain that Win32 paths
mixed with POSIX permission handling leads to surprising results.

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

And how many people get burned vice versa?  There is no "right" way,
there's just a way of least surprise and, even given your example, I'm
still convinced that the current behaviour is the behaviour of least
surprise.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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