This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CYGWIN=ntsec:[no]strict


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]