Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-developers-owner AT cygwin DOT com
Message-Id: <3.0.5.32.20021103142141.00815cf0@h00207811519c.ne.client2.attbi.com>
Date: Sun, 03 Nov 2002 14:21:41 -0500
To: cygwin-developers AT cygwin DOT com
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: Re: Solving ntsec problems?
In-Reply-To: <20021103180437.GA19854@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:04 PM 11/3/2002 -0500, you wrote:
>Pierre did you say that you had some patches which helped alleviate the
>ntsec problems that people are complaining about?

There have been fewer complains recently. Today I have seen something
about XEmacs interpreting r-x as non-readonly (not a Cygwin problem ?)
and something about ntsec and autotool.
http://cygwin.com/ml/cygwin/2002-11/msg00067.html
Interestingly that one said:
"I ran the cygwin setup as my normal user, and when prompted,
 gave it credentials for an administrator."
Compare it with what Rob said in
http://cygwin.com/ml/cygwin-apps/2002-10/msg00230.html
There is something fishy going on with non-privileged users.

To answer your question, I have 4 security related patches
on the way but I was waiting for Corinna to come back and review
them, as they raise design issues. 
The last one will have Cygwin automatically add an entry to the
internal copies of passwd and group (if needed) for the current
user. I wrote it yesterday, tested it on WinMe and will test it
on NT tomorrow. That will take care of domain users that don't
run mkpasswd -d and then ask why their name is Administrator
(but note that already with 1.3.14 such users shouldn't have
permission problems).
   
>I think we definitely need to add some logic to a postinstall script for
>setup so that executables are correctly chmod'ed and directories have
>the proper permission.
>
>It would be possible to kludge something along the line of _update_info_dir
>which gets run every time a package is installed to update /bin /usr/sbin,
>etc.   It would add noticeably to the amount of time taken by setup as it
>exits, though.  I just did a:
>
>cd /
>find bin lib usr etc -name '*.exe' | xargs chmod a+x
>
>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.

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. 
One drawback of using default is that the permissions are uniform
for all files in a directory, but that should be OK. Do we have
directories containing both executable and non executable files?
 
>I don't think we want to add ntsec awareness to setup.exe unless we
>want to make setup installation a two step process where the setup tar
>extraction relies on a cygwin DLL.  It would be nice to be able to
>rely on the permissions in the installation tar files being properly
>preserved on extraction.

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

Pierre