X-Spam-Check-By: sourceware.org
Date: Fri, 21 Apr 2006 11:38:02 -0500
From: mwoehlke <mwoehlke-nospam AT tibco DOT com>
Subject: Re: Cygwin and Interix interoperability?
In-reply-to: <20060421093909.GA12661@calimero.vinschen.de>
To: cygwin AT cygwin DOT com
Reply-to: cygwin AT cygwin DOT com
Message-id: <44490A6A.3090504@tibco.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5 (X11/20051201)
References: <4447BE05 DOT 6070103 AT tibco DOT com>  <20060420170449 DOT GA24155 AT trixie DOT casa DOT cgf DOT cx>  <20060420204058 DOT GA7685 AT calimero DOT vinschen DOT de> <44480053 DOT 609 AT tibco DOT com>  <20060421093909 DOT GA12661 AT calimero DOT vinschen DOT de>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
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

Corinna Vinschen wrote:
> On Apr 20 16:42, mwoehlke wrote:
>> True; it might require linking against Interix (yuck), which is only
>> feasible with SUA 5.2. There is nevertheless a very real chance that I
> 
> I don't think that's feasible for Cygwin, though.  Interix is not just a
> Win32 DLL as Cygwin, it's an entirely different subsystem.  I don't even
> want to know the implications when trying to link against the Interix
> subsystem.

I wouldn't expect it to be *easy*... however, SUA supposedly allows
"mixed-mode" applications, meaning Interix code is allowed to call into
the Windows subsystem. So the question is; can it work the other way?

>> Even better, believe it or not, the Windows subsystem actually
>> understands them! Which actually means that they are currently invisible
>> to Cygwin. If Cygwin could make these, then they would be understood
>> *transparently* by the rest of Windows (on NFS volumes, anyway)!
> 
> They are not understood by Windows, and that's documented.  They are
> just translated into the file type they are pointing to by the NFS
> client and then presented as file or directory to Windows clients.

Sorry for the confusion; that's what I meant. The point is, you can
request an open on a symlink (including symlinks in the *middle* of a
path) and it will transparently "work". That isn't the case for .lnk
files (and unfortunately, neither way works on non-NFS volumes yet).

IMO making them look like hard links is better than making them obvious
but less usable.

>> I would assume that there is a different interface for NFS permissions,
> 
> On the contrary.  All the Windows calls are naturally using the Win32
> security datatypes and so, even if there's an API, the POSIX permissions
> would have to be translated to Windows ACLs to make sense in Win32 calls.
> [snip]
> I made a quick test.  If you retrieve the security descriptor from a
> file or directory on an NFS share, you get the following information,
> all the time, regarless of the real owner, real group, and real permissions:
> 
>   Owner:  S-1-1-0 == "Everyone"
>   Group:  S-1-1-0 == "Everyone"
>   DACL:   NULL    == Full access for everyone.
> 
> [much snipping] It's really sad that NFS shares
> are not better than FAT file systems from the perspective of Win32
> applications.

Ok, I'll concede that the integration isn't as good as it could be.
However, it looks to me like what is happening isn't quite as grim as
you suggest. What I see is a: the Explorer interface displays the
correct attributes (even the right uid/gid if mapping is *not* set up
correctly), and b: the security API's seem to only give you the
attributes from the perspective of the user invoking the API (i.e. you
can't see what they would look like for other people).

At any rate, Cygwin *isn't* the Windows API... Why shouldn't Cygwin be
allowed to get it right for those API's that ask for POSIX-style
permissions?

How are you getting this information? Explorer won't give you "normal"
security attributes on an NFS volume... is there a command-line tool I
don't know about, or did you write your own?

-- 
Matthew
If you can't use a real OS, at least use Cygwin to fake one!


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