Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com From: "Hartmut Honisch" To: Subject: RE: Subauthentication Date: Fri, 13 Dec 2002 13:43:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021213130733.P7796@cygbert.vinschen.de> > > I see a legal issue though. If I understand the NT4 DDK license > agreement > > correctly, we're not allowed to freely distribute lsadll.lib > and ntdll.lib > > (even though it's available for free), which would be required to create > > cyglsa.dll. However, we should are allowed to use the lib-files > to create a > > dll (=> cyglsa.dll) and distribute that dll instead. If a > developer wants to > > build cyglsa.dll himself, he'll have to download the NT4 DDK > from somewhere, > > but I think that will be necessary very rarely. > > A question: When building the subauth dll, do you have to build > two versions, one for NT4 and one for 2k/XP? No. The same dll works on NT, 2K and XP. > Otherwise to workaround licensing... any chance to use autoload > techniques as in cygwin/autoload.cc? On NT, the required Lsa-Functions are not exported by any system dll. They're not even part of the operating system. So there's nowhere to autoload them from. On 2k and XP, they _are_ exported and therefore can be autoloaded from secur32.dll. > Otherwise we could just > change the creation of the subauth dll in the subauth directory > so that the make doesn't stop even though building of the dll > failed due to missing libs. At least we shouldn't have the > situation that a developer needs the DDK to build Cygwin. The subauth dll will always build. We would need those DDK lib files for the cygwin dll. Because the Lsa-functions are called from there, not from the subauth dll. The thing is that linking cygwin dll to the lsadll.lib will statically link it to ntdll.dll, which isn't available on 9x, so the cygwin dll would not work there. Our problem is Windows NT. If we want subauthentication to work on NT, we would have to build our "own" secur32.dll (with a different name of course: cyglsa.dll maybe?) that exports the required Lsa* functions. And to create that cyglsa.dll, we would need the DDK libs. Then: - If we're running on 9x, we never call any Lsa function - If we're running on NT/2k/XP, we would autoload the Lsa* functions; not from Secur32.dll, but from cyglsa.dll (we could autoload then from secur32.dll if running on 2k/XP and from cyglsa.dll on NT, but I'm not sure if the autoload algorithm can distinguish between different operating systems) However, we could of course just not support subauth on NT. Then we _could_ use the autoload stuff as it is now ... > ... It's way better than having no access to > network shares. Pierre applied some fixes to the cygwin security code, and since then, I'm also able to use network shares without subauthentication