X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 	tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
Message-ID: <921930.54424.qm@web110616.mail.gq1.yahoo.com>
References: <608157 DOT 47595 DOT qm AT web110616 DOT mail DOT gq1 DOT yahoo DOT com>  <hnpcg5$fls$1 AT dough DOT gmane DOT org>  <747800 DOT 43893 DOT qm AT web110615 DOT mail DOT gq1 DOT yahoo DOT com>  <20100324091522 DOT GS32321 AT calimero DOT vinschen DOT de>  <hofk9o$8bg$1 AT dough DOT gmane DOT org> <20100325130207 DOT GH7718 AT calimero DOT vinschen DOT de>
Date: Tue, 6 Apr 2010 17:25:09 -0700 (PDT)
From: Chris Idou <idou747 AT yahoo DOT com>
Subject: Re: Cygwin 1.7.1 breaks git on netapp shared drives
To: cygwin AT cygwin DOT com
In-Reply-To: <20100325130207.GH7718@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com



I still don't really understand what the issues are. What I will say is tha=
t I work in an organization with about 10000 people, and the chances I can =
ever get admins to change *anything* is next to nil, let alone change acls =
for some program that is probably not even on some stupid approved list the=
y have.

It doesn't seem to me that there is any good reason why a utility like git =
shouldn't be able to work in this scenario. Whether git needs modifications=
, or cygwin I don't know, but I don't see why git *needs* to have permissio=
n changes work in order to be a functional repository. Maybe someone can fi=
nd out whose problem this is and report it?





----- Original Message ----
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Sent: Fri, 26 March, 2010 12:02:07 AM
Subject: Re: Cygwin 1.7.1 breaks git on netapp shared drives

On Mar 25 07:17, Steve Bray wrote:
> On 03/24/2010 04:15 AM, Corinna Vinschen wrote:
> >On Mar 23 16:37, Chris Idou wrote:
> >>
> >>
> >>After a heck of lot of screwing around, I got this mount point stuff wo=
rking. Now when I create files under cygwin they have the same permissions =
profile as they do when I create them under windows.
> >>
> >>BUT...
> >>
> >>git doesn't work still. It fails with the exact same error of "unable t=
o set permission". How do the cygwin APIs work under noacl? They shouldn't =
ever return error code should they?
> >
> >They should.  There's the one case in which you're trying something like
> >chmod 444.  Under noacl conditions this sets the DOS R/O attribute.  If
> >that fails, the call fails.
> >
> >
> >Corinna
> >
> In my original post I acknowledged that we can not make NTFS ACLS
> exactly match POSIX behavior.  The best that we can do is consider
> the impact of our choices.
>=20
> The cygwin 1.5 behaviour often failed to report chmod failures but
> many of us have been happily using cygwin for a long time and never
> noticed.

Cygwin 1.5 chmod already failed if ntsec was set and changing the ACL
failed.  You probably didn't realize it because "nosmbntsec" was the
default for remote drives.

> With cygwin 1.7 the trade-offs in handling NTFS ACLS were changed.
> chmod failures are now reported but now chmod fails unless the user
> has NTFS ACLS that support changing permissions.  All of the Windows
> shared drives, that are secured, do not give users permission to
> change permissions on the files that they create and own.  This does

Which is bad by design.  Permissions on shares should be set in the
ACLs of the remote drive, not by mis-using a badly designed sharing
permission model.
Anyway, you can use "noacl" on a by-share base.  That's even better
than in 1.5.

> In our case we still had permissions on our shared drive to write
> attributes and extended attributes.  In any case, after mounting
> with noacl git can change the RO flag and is functional.
>=20
> I was not able to test a condition that blocked changing the RO flag.
> I removed ACLS for write attibutes, write extended attributes (and
> change permissions) but chmod and git were still able to set the
> files RO.  My permissions might be leaking through in some way.  I
> have only one account and limited permissions to do much
> investigation.
>=20
> If Chris is in an organization that removes permission to change
> either ACLS or the RO flag, then how does he use cygwin and git?

He should put that to the admins.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:      http://cygwin.com/problems.html
FAQ:                  http://cygwin.com/faq/
Documentation:        http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple