Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Subject: Re: Solving ntsec problems?
From: Robert Collins <rbcollins AT cygwin DOT com>
To: cygwin-developers AT cygwin DOT com
In-Reply-To: <20021103215859.GA21874@redhat.com>
References: <20021103180437 DOT GA19854 AT redhat DOT com>
	<3 DOT 0 DOT 5 DOT 32 DOT 20021103142141 DOT 00815cf0 AT h00207811519c DOT ne DOT client2 DOT attbi DOT com> 
	<20021103215859 DOT GA21874 AT redhat DOT com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-6rvIHDbYKJiuyWKYiCTE"
Date: 04 Nov 2002 09:09:14 +1100
Message-Id: <1036361355.22120.31.camel@lifelesswks>
Mime-Version: 1.0


--=-6rvIHDbYKJiuyWKYiCTE
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-11-04 at 08:58, Christopher Faylor wrote:

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

I'd rather extract the ntsec unix->win32 acl logic to a static library
that both cygwin1.dll and setup.exe can incorporate. If the translation
alters in a fundamental way, we can simply relink setup to get a new
version (and with careful thought we could even 'upgrade' all the acls
in the users tree to the new translated fashion when setup runs next).

Setup can track should-be-executable programs, and run a script with all
of them named, but IMO thats a kludge. Giving setup ntsec awareness
(with some additional 'when etc/passwd is missing do foo' logic) is a
generic solution.
=20
> >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"=20
> >set the parent directory acl properly would be the way to go.
> >Users could control the permissions of new files (say choosing=20
> >between 777 and 755) by using the Windows GUI or setfacl to set
> >the default in the parent.=20
>=20
> Don't know.  Maybe someone who is familiar with setup.exe can chime
> in.

I'd need to check. Corinna contributed some code a while ago IIRC.

Rob
--=20
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---

--=-6rvIHDbYKJiuyWKYiCTE
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9xZ6KI5+kQ8LJcoIRAjdoAKCpfMO0ZeGvGQQswhqruxhs6XlvfwCfTarw
j12ywCWW3S/paBsUSyICOr4=
=xVHw
-----END PGP SIGNATURE-----

--=-6rvIHDbYKJiuyWKYiCTE--