MSYS mode (continue)

[Charles Wilson]

On 7/25/2013 11:02 AM, Corinna Vinschen wrote:
> On Jul 25 09:11, Charles Wilson wrote:
>> On 7/11/2013 7:17 AM, Corinna Vinschen wrote:
>>> The hooking itself is the lesser problem.  What I'm rather wondering
>>> about is how the MSYS helper DLL comes into action.
>>>
>>> Ideally, MSYS executables would actually be Cygwin executables, linked
>>> against the Cygwin DLL.  The advantage being that the executable could
>>> run in an MSYS and a Cygwin environment, whatever it happens to be
>>> dropped into.
>>>
>>> The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries
>>> to load the MSYS DLL dynamically.  Either loading the MSYS DLL works or
>>> it doesn't, but if it works, it could just call cygwin_internal in it's
>>> dll_entry function to set up the hooking mechanism.  If it fails, the
>>> executable works as a plain Cygwin executable.
>>
>> I dunno. Back in 2009, I (re)built and updated to then-current EVERY
>> single element of MinGW.org's msys distribution.  There were a LOT
>> of patches required, which were not required on cygwin.
>> [...]
>
> In how far does this affect us today?  The idea to have a Cygwin DLL
> underneath and just add the MSYS functionality by linking one way or
> the other allows to get rid of lots of old workarounds.  There's no
> reason to stick with the old ways.

Right, that's what the paragraph you snipped was about.

>> However, many of the patches were to handle differences inherent in
>> the environment.  For example, msys-make kept the "allow X:/foo/bar
>> paths in rules" patch, which cgf long ago removed from cygwin-make.
>> [...]
>
> This isn't relevant.  The idea is to have a different crt0.o which
> allows to get the MSYS specific functionaily by building an application.
> against it.  This does not reduce the necessity to patch applications
> which require special functionality like a DOS-path-resistant make.

Ah, but you're assuming that the app itself is *recompiled* so that it 
links a different crt0.o.  I interpreted your statement:
	"The advantage being that the executable could run in
	 an MSYS and a Cygwin environment, whatever it happens
	 to be dropped into."
to mean "the exact same binary".  That misunderstanding is what led to 
most of the confusion below.

My point is, I don't think *that* would work, for all the reasons I 
detailed.

>> But some apps (and our config-foo scripts!) check those settings;
>> for instance, ssh.exe wants to ensure that ~/.ssh is not writable by
>> anybody except the owner. That stuff had to be patched out, to work
>> on msys.
>
> Which is bad.  I removed some older code from ssh specificially per the
> request from the upstream devs since they thought it's too unsecure.
> It's kind of frustrating having others adding this stuff back in just
> to stay happily unsecure.  Windows 95 is long gone.

Of course it's bad. MSYS(current version), based on cygwin-1.3.x AND 
with an even more broken security model than 1.3.x had, sux when 
compared to modern day cygwin.

However...a LOT of people don't care about file security when operating 
in a network environment that is deemed "protected" from outside 
interference.  E.g. network shares on an internal lab network, etc.  At 
$dayjob, I've seen folks get really annoyed by the issues that crop up 
when trying to mix native tools and cygwin's security model [1].

[1] the magic
----------+ 1 me mygroup 1.4M Jul 25 11:51 some-file
permssion settings you get when some-file was created using win32 tools.

So, they prefer MSYS no-security model, because in a protected network, 
they just want to get their job done, and not spend time chmod'ing stuff 
(or, in severe cases you can get yourself into a jam where you don't 
even have permission to "fix" it, and you have to get some IT support 
guy with Local Administrator privilege to do it. "And how did you create 
this file? What where you doing?").

So...if your msys-on-cygwin implements $dumb-security, then...no ssh at 
all?  (Geez, I've seen people store their ~/.ssh on a network share, 
which is...counterindicated, at best. But it's still done.)

>> Well, we don't want $real-cygwin's ssh.exe to act in such an
>> insecure manner, but then cygwin-as-msys users lose out, unless then
>> only use the ssh.exe from their parallel installation of
>> $real-cygwin.
>
> And the disadvantage is...?  The whole idea is to be able to stick to
> full-fledged Cygwin functionalitiy, except for the cases where it
> revolves around building native applications and DOS path handling.
> There's no good reason to duplicate everything in an incompatible
> way.

I thought the "whole idea" was to replicate the existing msys toolkit 
(which currently includes rsh, ssh, and an extremely limited subset of 
the cygwin universe), only with a better, more maintainable core msys 
dll (which is actually cygwin1.dll + the extra hook-impl-providing msys 
thingy).

>>> Alternatively, MSYS crt0.o itself provides all the necessary functionality,
>>> which might be a lot easier to implement.  It could call cygwin_internal
>>> and provide the necessary callbacks and it would be linked against the
>>> Cygwin DLL "just so".
>>
>> I think you would actually need an entirely separate distribution of
>> tools,
>
> That was the point, Chuck.  The idea was to have an MSYS distro with
> tools linked against the special crt0.o to get the aforementioned extra
> functionality.

Ah, so you're not talking about dropping in "the same executable" into 
the MSYS arena and expecting its behavior to magically change. 
C:\cygwin-msys\bin\make.exe is a different binary than 
C:\cygwin\bin\make.exe.

OK so far.

> But underlying there's still a normal Cygwin DLL and
> most tools could just be copied verbatim since they don't need this
> extra functionality.

And that's the bit where I disagree.  Sure, some scripting tools might 
not need adjustment, so long as their interpreter was $MSYS-enabled 
(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
dos-style paths, so its interpreter better be able to handle them.

But unless you restrict yourself to only passing around relative paths 
(or god forbid, that old "unity mount" idea), any .exe will need to live 
in one world or the other. Otherwise, how would paths be interpreted? 
Using which tools' mount table?

Naturally from the command line I can compensate:

msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
-d /msys/mount/table/path) )

but yee gods that'd be annoying in any automated setting.

--
Chuck