delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2003/02/27/22:52:55

Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-Id: <3.0.5.32.20030227224844.0080be90@incoming.verizon.net>
X-Sender: vze1u1tg AT incoming DOT verizon DOT net
Date: Thu, 27 Feb 2003 22:48:44 -0500
To: cygwin-developers AT cygwin DOT com
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: Re: CYGWIN=ntsec:[no]strict
In-Reply-To: <20030228032655.GA22913@redhat.com>
Mime-Version: 1.0

At 10:26 PM 2/27/2003 -0500, Christopher Faylor wrote:
>I was wondering if it would make sense to have cygwin default to
>a somewhat looser interpretation of POSIX correctness wrt protections.
>I was considering that maybe a file with a .exe, .bat, .cmd extension
>should always be considered executable regardless of protection.

I would refrain from doing any such thing until both:
- 1.3.21 is out. Unfortunately 1.3.20 has a bug that degrades the mapping
  between acl and permissions, for files created by non-ntsec programs 
  (such as setup). Also sh "test" (and soon bash and /bin/test (?)) will
  reflect the *true* permissions in 1.3.21. 
- The new setup is out, with my ntsec patch. That will greatly alleviate
  the problem you describe in the next paragraph.
 
>It seems like we are consistently confusing people who, after an
>install, find that their programs are not considered to be executable by
>cygwin.  I'm not sure why this is happening (does someone understand this?)

Yes, but there are several cases. The main one is that on many systems
the default ACL gives no permissions for Everyone, and in exchange the
permissions are wide for Users. However that is not reflected in the
permissions bits because the file group is None, and the ACL gives no access
to None either.

The stock answer should be to chmod +x the entire tree.
 
>but it seems like just reverting to the behavior where a file with a .exe
>extension is always considred a+x would relieve this problem.
>
>I don't like making this undefeatable however, so I was thinking that
>adding a "[no]strict" option to ntsec might be a way to avoid this
>behavior.  So, CYGWIN=ntsec:strict would emulate the current behavior
>where CYGWIN=ntsec:nostrict (my proposed default) would use the above
>indicated behavior.
>
>Is this a stupid idea?

No, but then you will run in the situation where a file is truly non 
executable but the x bit appears to be set. 
Worse, I believe that when one chmod a file, the chmod command first 
does a stat and it only applies the new mode if necessary. 
So if the file is not, but appears to be, x, chmod may do nothing on
a +x ....

Pierre

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019