This is the mail archive of the cygwin 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: Can "DLL's" & libraries be marked as non-executable?

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" " "
/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"

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

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...

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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