Solving ntsec problems?

Christopher Faylor cgf@redhat.com
Sun Nov 3 13:57:00 GMT 2002


On Sun, Nov 03, 2002 at 02:21:41PM -0500, Pierre A. Humblet wrote:
>>and it took 27 seconds.  That was after messing around with the find
>>command so some of the files/directories were probably already in
>>"cache".  This is on my dual PIII 733MHZ system.
>
>There was an objection to this earlier, to the effect that users may
>choose to turn off x on some programs and that setup shouldn't silently
>turn it on again. So I'd rather offer a fixup script that users can run
>once explicitly to fix the current situation, and then try to insure that
>future installs set the correct permissions for new files.

I've reached the point where I think this is one of those cases where
its better to be fixing things for the common case than catering to
people who have special needs.  If there are people out there who are
populating their /usr/bin area with non-executable files then they
can take special steps to recreate permissions after running setup.

OTOH, one thing that we could do is only turn on executable bits that
exist in the tar archives since those are still available..  We could
have something which does a fixup only on extracted files which are
supposed to be executable.

>Do we know how those permissions are set? Are they set explicitly
>by setup, or are they based on the inheritable permissions of the
>parent directory (default)? If so having the "fixup script/program" 
>set the parent directory acl properly would be the way to go.
>Users could control the permissions of new files (say choosing 
>between 777 and 755) by using the Windows GUI or setfacl to set
>the default in the parent. 

Don't know.  Maybe someone who is familiar with setup.exe can chime
in.

>>Anyway, while 1.3.14 seems to have solved some problems, I'm still
>>concerned by the number of people struggling with ntsec issues.  I'd
>>like to start taking active steps to solving these problems.
>
>If you see something specific, please forward it to me just in case
>I miss it.

The emacs thread was pretty long running and there was a lot of churning
about the best way to fix things.  It seems like the solution of choice
for most people is to set CYGWIN=nontsec which is a shame.

cgf



More information about the Cygwin-developers mailing list