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 Message-ID: <41EC550F.3050609@tlinx.org> Date: Mon, 17 Jan 2005 16:15:11 -0800 From: linda w User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Can "DLL's" & libraries be marked as non-executable? References: <41E9D722 DOT 3010306 AT tlinx DOT org> <009001c4fba2$54223c20$e6ec6f83 AT robinson DOT cam DOT ac DOT uk> <41EAF139 DOT 6070102 AT tlinx DOT org> <41EAFB0B DOT 8080501 AT familiehaase DOT de> In-Reply-To: <41EAFB0B.8080501@familiehaase.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Gerrit P. Haase wrote: > Try to chmod 644 any dll and call a program that uses this dll. > This fails for me (on NT4 with NTFS), if it succeeds for you, fine. > Change the permissions as you like it;) --- Actually, chmod makes no difference on on FAT32. Note, I'm having to rewrite this note from scratch, as I'd composed most of it over 2-3 hours (I'm a slow typist and have to take many breaks) only to have Thunderbird crash. It turns out, unlike GVIM, Outlook, Word and other compose clients, Tbird doesn't auto-save drafts periodically and doesn't appear to be configurable to do so. So, *duh*, I'll compose this one in vim -- at least it autosaves the .swp file periodically. Anyway, might I suggest that some of these compatibility issues could be addressed by settings in the CYGWIN env variable -- specifically, perhaps, setting "NTSEC", might have chmod and "executable command" set and/or check the executable flags of the underlying OS. Otherwise, chmod would have no effect on the "x" bit, (would act like chmod +w on an ext-based "immutable" file). The native NT commands could still be used to modify native NT file bits, otherwise, only PATHEXT extensions could be used to determine executables with one exception: extensionless files. There, the current behavior is likely to cause least surprise. Option (not really needed or desired by myself): -- check the contents of the file, however, setting another flag in the CYGWIN env-var might disable this even for extensionless files -- if a user wanted the performance increase and was "always" willing to add an extension to script files (obviously this would be "incompatible" with the current default installation). However, currently, if you have a "shell script" in a file, it still may not be treated as an executable on FAT32. Example: /tmp> cat >cnv_lf2spc cat |tr "\n" " " #eof /tmp> ll cnv_lf2spc ## note non exec -rw-r----- 1 law 22 Jan 17 13:31 cnv_lf2spc /tmp> chmod +x cnv_lf2spc /tmp> ll cnv_lf2spc ## chmod+x has no effect -rw-r----- 1 law 22 Jan 17 13:31 cnv_lf2spc but add the right magic to the front of the file and it appears to be an executable no matter what the name or the chmod status: /tmp> (echo "#!/bin/sh";cat cnv_lf2spc)>cnv_lf2spc.txt /tmp> ll cnv* -rw-r----- 1 law 22 Jan 17 13:31 cnv_lf2spc -rwxr-x--- 1 law 32 Jan 17 13:33 cnv_lf2spc.txt* /tmp> chmod -x cnv_lf2spc.txt /tmp> ll cnv* ## setting chmod-x makes no difference -rw-r----- 1 law 22 Jan 17 13:31 cnv_lf2spc -rwxr-x--- 1 law 32 Jan 17 13:33 cnv_lf2spc.txt* /tmp> cp cnv_lf2spc.txt cnv_lf2spc.html /tmp> ll cnv* ## html files can be "commands too" (!?desired?) -rw-r----- 1 law 22 Jan 17 13:31 cnv_lf2spc -rwxr-x--- 1 law 32 Jan 17 13:33 cnv_lf2spc.html* -rwxr-x--- 1 law 32 Jan 17 13:33 cnv_lf2spc.txt* The above behavior will happen on any Win9x/Me or FAT32-based cygwin install. I believe the POSIX "executable" bit is primarily aimed at determining what files are meant to be executable commands -- not what files may contain libraries of executable code. True, you can have a "DLL" be self-registering if run as an "exe", but that is sufficiently specific to the Windows OS as to be only 'invokable' with the "cygstart" facility. Having a default behavior where the internals of 'extensioned' files are not opened would significantly speed up 'statting' and perhaps general execution of cygwin commands. It certainly could speed up 'find' as used in 'updatedb' (which takes the better part of or more than an hour to run on my system). Optional (not really needed by me, but could be implemented if someone wanted to put in the time): One could support Posix style attributes on FAT32 based files by creating an external hashed file to store the names of those files that had explicit "chmod" commands executed on them that changed the default attributes. To guarantee the integrity of such a file, one would need to implement a Journalling system as Windows does with the registry hives -- a ".log" file that is syncronously written to along with hive updates. the mechanism could be built from scratch, or the builtin hive facility could be used -- with the first load of cygwin.dll in a session checking to see that the cyg-sec hive was loaded. After it was loaded, the updating and the integrity of the hive would be handled by the native OS. Such "external security attribute" files have successfully been used successfully to implement multi-level security attribute requirements on Trusted *nix systems on top of file systems that didn't support extended attributes on files (i.e. Trusted Irix on EFS, SGI's predecessor file system to XFS). The security built-in to the Operating system precluded direct modification of those files -- much in the same way that it's difficult to directly modify Win[NT-based] registry files. But for short-term, it seems that honoring extensions set in PATHEXT and peeking inside "extensionless" files would provide POSIX/gnunix compatible operation for 99% of users. As a backup, a flag in the CYGWIN env var could specify the old behavior to "peek" inside every file to determine if it was an "executable", and a 2nd flag, "LIBS_EXEC" (?), could be used to include libraries as executable commands. Marking .dll's, ocx's, etc as "commands" under POSIX doesn't seem particularly compatible with the "spirit" of what is generally considered to be a POSIX/gnunix command and using native extensions along with peeking, only for non-ext files would seem to provide maximum compatibility while providing gains in execution speed. A simple means to include DLL's as executable commands would already be included: include the ".DLL" extention in the PATHEXT environment variable. Instead of picking apart why the details of things that don't work with my proposal, could I ask that you propose ways that require minimum code change that could enable better distinguishing of POSIX/gnunix "commands" from files not intended to be "commands"? Thanks for any help... Linda -- 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/