delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2002/12/13/07:43:32

Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
From: "Hartmut Honisch" <hartmut_honisch AT web DOT de>
To: <cygwin-developers AT cygwin DOT com>
Subject: RE: Subauthentication
Date: Fri, 13 Dec 2002 13:43:25 +0100
Message-ID: <NFBBLLCAILKHOEOHEFMHGEAJCEAA.hartmut_honisch@web.de>
MIME-Version: 1.0
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019