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: <41EAF139.6070102@tlinx.org> Date: Sun, 16 Jan 2005 14:56:57 -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> In-Reply-To: <009001c4fba2$54223c20$e6ec6f83@robinson.cam.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Max Bowsher wrote: > linda w wrote: > >> Is there some reason cygwin needs to return DLL's as executables, as the >> underlying OS doesn't require it (having no 'executable bit'). > > Wrong, actually the underlying OS *does* require it. It may not have > mode bits, but it does have ACLs. Before calling me wrong, you might ask about my configuration. You put create an unnecessarily confrontational position which is not productive (or polite). I'm using FAT32. There are no ACL's on FAT32. Might I suggest that your statement of 'wrongness' doesn't apply, universally. This is especially if anyone is still using Win98 or ME which is still the case for some users (I run FAT32 on XP because I benched it as being 2-4x faster than NTFS). I use it on a laptop, where I'm already speed-strapped enough). Even if the NT ACL returns "executable" for DLL's, it's still not in the spirit of the POSIX/gnunix executable bit. Just as directories have an 'executable' bit to set, that doesn't mean they _are_ 'executables'. I'm suggesting that having DLL's be marked as executables in the *nix/Posix sense doesn't seem to be useful for a Gnunix environment as Gnunix doesn't require or expect libraries to have the executable bit set. It, not only doesn't seem useful, but does cause POSIX compliant apps expecting executable files to be user commands to not function as would be expected in a POSIX/gnunix environment. This wouldn't seem to be a desirable 'feature'. Could you please rethink how the executable bit should be propagated by cygwin -- the executable bit is obviously being simulated by looking at extensions and file contents -- not simply by the presence or absence of an executable bit. Possibly the NT ACL's could be accessed through the POSIX 1003.1e Draft Standard (#17 being last update). While it lacked quorum for passing by the time it reached agreement in the committee, it has been used as a reference by Sgi and Linux security interfaces with the SGI Trusted Irix interface achieving a successful evaluation at the CAPP and LSPP security levels as specified under Common Criteria (roughly corresponding to old DoD Orange Book levels C2 and B1). More to the point, what would "break" in the cygwin environment, if libraries were excluded from being considered "executables". The NT executable bit doesn't have the same semantics as the POSIX/gnunix executable bit, since the cygwin loader can choose to 'load' DLL's as executable code regardless of an executable bit being set -- just as it must do on Win98 or any FAT32 based system. -- In the marketplace of "Real goods", capitalism is limited by safety regulations, consumer protection laws, and product liability. In the computer industry, what protects consumers (other than vendor good will that seems to diminish inversely to their size)? -- 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/