Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.1.0.14.2.20020714200721.02c7b328@pop3.cris.com> X-Sender: rrschulz AT pop3 DOT cris DOT com Date: Sun, 14 Jul 2002 20:19:10 -0700 To: Jehan , cygwin AT cygwin DOT com From: Randall R Schulz Subject: Re: Permission denied on a windows share In-Reply-To: References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020713194509 DOT 02bb9210 AT pop3 DOT cris DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020713204337 DOT 02acf938 AT pop3 DOT cris DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020713220237 DOT 02acf568 AT pop3 DOT cris DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed [ I hope someone who understands these issues better than I do will correct me if I'm mistaken and / or misleading Jehan... ] Jehan, Have you read the Cygwin documents regarding file modes / permissions and how they relate to Windows permissions? At 10:44 2002-07-14, Jehan wrote: >Randall R Schulz wrote: >>The reason is the mapping between Cygwin's Unix / POSIX permissions and >>Windows is not reversible. Windows permissions are far more refined, so >>it is inevitable that in at least one case (in reality, many cases), >>there are multiple distinct Windows permissions that map to a single >>Cygwin / Unix / POSIX file "mode." > >And? I don't understand the point. All that tells me is that "ls -l" may >not show the real permissions because Windows persmissions doesn't always >map to Unix/POSIX. That's fine with me. That would be the explanation for >an application failing when it checks explicitly for permissions. But I >don't think "cat" and "cp" do any permissions checking, they fully rely on >the underlying system for that. "Cat," "cp" and any other program linked with Cygwin relies on Cygwin to do permission checks. When ntsec is in effect Cygwin simulates / synthesizes POSIX-style file modes based on the Windows permissions. This is a many-to-one mapping from distinct Windows permissions to "equivalent" POSIX ones. There's no way around it. This is one of the places where it's not possible for Cygwin to create a fully seamless integration with Windows. >What I don't understand is why cygwin doesn't rely on Windows. For what I >know of ntsec, it sets the permissions/ownership of files. It also read >them so "ls -l" show correct permissions (as much as possible knowing that >not all Windows permissions map to Unix). >But once their are set, then Windows should be able to take care of >denying/allowing access accordingly. Why would cygwin need to do more >security checking than Windows does? Why would cygwin deny me write access >to a file when I can do it with any other Windows application? If the mapping from Windows permissions to POSIX-style file modes says the file is inaccessible, Cygwin must deny the program access even if Windows would allow it. You've asked Cygwin to do that be enabling "ntsec." >>Cygwin will "leave it to Windows" if you turn of "ntsec" and / or "ntea." > >I know, it used to be that way. But then I don't see what file belong to >who and what I am allowed to do. The bottom line is that a POSIX-style file mode is inherently and ineluctably an imperfect reflection of the essential Windows permissions. You must live with the discrepancy. > Jehan Randall Schulz Mountain View, CA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/