Cygwin and Interix interoperability?

[mwoehlke]

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/