Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Tue, 7 Aug 2001 18:38:13 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: outstanding issues blocking new release?
Message-ID: <20010807183813.A28586@cygbert.vinschen.de>
Reply-To: cygdev <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20010806213235 DOT A24499 AT redhat DOT com> <20010807105917 DOT F22015 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010807105917.F22015@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Aug 07, 2001 at 10:59:17AM +0200

On Tue, Aug 07, 2001 at 10:59:17AM +0200, Corinna Vinschen wrote:
> 3) Setup is prepared and changing fhandler_base::open() shouldn't
>    be too hard since most of the code already exists (alloc_sd).
>    I just need a few hours to wrap it for usage in open() and to
>    test the stuff. So, if you're not in a hurry...

That was way easier than I estimated. And I have learned something new:

The SECURITY_ATTRIBUTES given to the CreateFile() call does _not_ only
describe the security settings for the returned handle as I thought
all the time. Instead it has actually two purposes:

- The bInheritHandle member sets the inheritance property for the returned
  handle.
- The lpSecurityDescriptor member sets the security descriptor for the
  created file, actually.

And the CreateDirectory() function has a SECURITY_ATTRIBUTES parameter
as well.

That means, the open(), symlink() and mkdir() calls now don't open
the file/dir a second time to write the NT security settings as before
but the settings are already done in the CreateFile()/CreateDirectory()
calls.

Why didn't I realize that already two years ago???


=================================================================
     IMPORTANT QUESTION!
=================================================================

BTW, that has an interesting side effect. The propagation of
permissions from the parent directory is no problem anymore when
creating files in directories which aren't owned by the creator
of the file. That problem was the main reason to switch off the
propagation completely when creating directories. The explicitly
given security descriptor in the CreateFile()/CreateDirectory()
calls rules.

So the question is:

Shall we return to propagating permissions to subfolders and files?
-------------------------------------------------------------------

The advantage is that native windows applications would create files
with useful permissions again.

Since 1.3.2 still propagate permissions, non-developer users wouldn't
even realize that something has changed. Even users who don't upgrade
to the latest setup.exe wouldn't have the problem which Charles stumbled
over. Sorry, Charles! It seems as if you has been sort of a guinea pig...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.