Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs Date: Thu, 4 Dec 2003 23:28:33 -0500 (EST) From: Igor Pechtchanski Reply-To: cygwin AT cygwin DOT com To: Yap on ExactGeom cc: cygwin AT cygwin DOT com Subject: Re: Hello and cygwin quesiton In-Reply-To: <3FCFEB95.2030100@cs.nyu.edu> Message-ID: References: <3F7A1AC0 DOT 3050503 AT cs DOT nyu DOT edu> <3F7B0C4E DOT 4090000 AT cs DOT nyu DOT edu> <3FCFEB95 DOT 2030100 AT cs DOT nyu DOT edu> Importance: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Chee, '/bin/vi' is a Cygwin program, and uses Cygwin system calls to create and write files. Thus, the permissions it gives to newly-created files are consistent with the other Cygwin apps. 'gvim' is probably a pure Windows program, which uses the Windows API calls directly, so it gives new files the same Windows permissions as, say, notepad does. As I mentioned before, this is the way Windows behaves by default: the files inherit the ACLs of the parent directory. Cygwin actually fixes up the ACLs later to make them more reasonable. For example (feel free to skip the following unless you want details): ======================== begin listing ======================== $ cmd /c 'type nul > a.txt' $ cacls a.txt C:\cygwin\tmp\acltest\a.txt BUILTIN\Administrators:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_EXECUTE FILE_READ_EA FILE_EXECUTE FILE_READ_ATTRIBUTES PECHTCHA\igor:F Everyone:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_EXECUTE FILE_READ_EA FILE_EXECUTE FILE_READ_ATTRIBUTES $ touch b.txt $ cacls b.txt C:\cygwin\tmp\acltest\b.txt PECHTCHA\igor:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES BUILTIN\Administrators:(special access:) READ_CONTROL FILE_READ_EA FILE_READ_ATTRIBUTES Everyone:(special access:) READ_CONTROL FILE_READ_EA FILE_READ_ATTRIBUTES $ ========================= end listing ========================= Note that the :F (full access) contains the following permissions: STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES For people on this list who are interested, the relevant ACL allocation code is in the alloc_sd() function in winsup/cygwin/security.cc. In short, there's really not much you can do, other than, perhaps, turn off "ntsec" (by adding "nontsec" to your CYGWIN environment variable, see and ) at the risk of some services not working, e.g., cron, sshd, etc. Or you could change the permissions by hand every time. Or, if all you care about is how the files are displayed, use the dircolors command ("man dircolors" for details). Igor On Fri, 5 Dec 2003, Yap on ExactGeom wrote: > Dear Igor, > I guest there were no improvements on the execute permission problem. > > But I just realized that "vi" under cygwin is smart enough > not to give execute permissions to the files it writes > out. It simply keep the original permissions. Why can't gvim > do the same? > > Best, > --Chee > > Igor Pechtchanski wrote: > > >Chee, > > > >Well, there are people on this list who are more versed in Windows > >permissions issues than I, and hopefully they'll intervene and either > >confirm or refute my answer. If I had to guess, I'd say this has to do > >with inheritable permissions -- if a directory has an execute permission > >and the flag is set that makes all files and subdirectories inherit that > >permission, all your files will be marked executable. You can try to use > >the Windows permissions dialog to uncheck the "allow objects to inherit > >permissions" box, and this might solve the problem. I'm not sure why you > >didn't have this problem on Win2k (I do), but it could be because of some > >unique permissions setup. > > > >Hope this helps, > > Igor > > > >On Wed, 1 Oct 2003, Yap on ExactGeom wrote: > > > > > > > >>Dear Igor, > >>Nice to hear from you, and thanks for the clarification! > >> > >>I understand your explanation of the difference between > >>gvim and vim. But there is still a mystery. > >> > >>In my previous installation of cygwin, no such problems > >>arise. The difference is that my previous system was Windows 2000 > >>and my current one is Windows XP. Can you explain this? > >> > >>Thanks, > >>--Chee > >> > >>Igor Pechtchanski wrote: > >> > >> > >> > >>>On Tue, 30 Sep 2003, Yap on ExactGeom wrote: > >>> > >>> > >>> > >>>>Dear Igor, > >>>> > >>>>How are you? I noticed that you are an active developer of cygwin. > >>>>I really liked this platform and our Core Library is developed > >>>>on this mainly. I have a question: > >>>> > >>>>In my recent (June) installation of cygwin, there was an annoying > >>>>bug -- many of the files that I create are automatically given > >>>>the execute permission. [Since my "ls" will automatically show > >>>>me which files are executable, this is VERY annoying.] > >>>>But this behavior is not universal. If I have a non-executable > >>>>file, and I exit it using gvim, the file will become executable. > >>>>But using vim, it remains non-executable. But I don't think > >>>>the program is with a bad installation of gvim, because this > >>>>phenomenon shows up in other places. > >>>> > >>>>Heard of this bug before? > >>>>Thanks, Chee > >>>> > >>>> > >>>Hi, Chee, > >>> > >>>Great to hear from you. > >>> > >>>I'm redirecting this reply to the general Cygwin list, mostly to get this > >>>into the archives (because I know others are having this same problem). > >>>Also, this brings your question up before a large body of expertise -- > >>>perhaps someone else will find something I've missed. > >>> > >>>This is not a bug, but rather an artifact of the default permissions files > >>>get when written by Windows programs. Gvim is a pure Windows program, in > >>>contrast with vim, which is a Cygwin one. Also, vim writes files > >>>in-place, whereas gvim creates a new copy -- hence the change in > >>>permissions. Unfortunately, there isn't anything you can easily do to fix > >>>this. I have a script (attached) that I run periodically on my system to > >>>fix the executable permissions. It's not foolproof, but it's better than > >>>nothing (and it should err on the conservative side). > >>> Igor > >>>[fixexec script snipped] > >>> > >>> > > > > > > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/