What I need (was Re: Using winbind with Wine)

2002-10-23 Thread Martin Wilck
First of all thanks everybody for the feedback.

It seems that Wine/Samba integration will not be a solution for general
Wine RPC, at least not in the short term.

However I have determined the functionality I need and I think most of
it can be implemented on top of existing winbind functionality as I
originally intended.

These are the functions I need:

LogonUser(ADVAPI32) - can be done through pam_winbind to authenticate
  against PDC

NetGroupGetUsers- Can be implemented with nss_winbind's getgrent()

NetGroupGetInfo - Also getgrent() (?)

NetLocalGroupGetMembers - Hmm - I don't think Windows' local/global
  group distinction makes sense on Unix -
  windbind looks for global groups, I suppose?

NetGetDCName- Get name of primary domain controller - 
  seems to be the most difficult part.
  Could be solved by simply looking it up in the 
  Samba config file.

This approach means that the respective functions are not really carried
out as Windows RPCs - for example the servername argument to these
functions will be ignored because I cannot tell winbind on which server
to execute its RPC. 

Even if wine had a fully-fledged RPC implementation I doubt that would
be reasonable to implement these functions on top of that, because
groups and users really need to be mapped to their Unix equivalents.

Comments welcome!

Martin


Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com
D-33106 Paderborn   http://www.fujitsu-siemens.com/primergy








Re: Using winbind with Wine

2002-09-26 Thread Simo Sorce

Imho the best way to go, is to wait until we will be able to provide an
interface for loadable modules in samba that couples with the MS-RPC
subsystem.
At that point you will only need to make the .so library as GPL and
build your socket mechanism to speak to the other LGPLed end integrated
into wine.

Simo.

On Thu, 2002-09-26 at 13:47, Martin Wilck wrote:
 Am Mit, 2002-09-25 um 19.38 schrieb Richard Sharpe:
 
  I do not think that libsmbclient is the right way to do this. I think that 
  the correct way is to make the various Samba client RPC libaries available 
  as separate DSOs so that clients can make dirrect use of what they need. 
  Then the wine group can possibly build a thing DLL wrapper around the 
  underlying RPC libraries.
 
 Licensing is an important issue.
 
 I future Samba RPC libraries come with GPL, they won't be usable for
 Wine (as you probably know, Wine is LGPL and ReWind X11). I don't want
 to start a licensing debate here. I expect the Samba team to release
 their stuff GPL'd in the future, thus I accept is as a fact that Wine
 cannot be linked to Samba libraries, present or future.
 
 For that reason I find the winbind concept of socket communication
 attractive. To my understanding this would not raise license issues. We
 are not currently worried about performance, we just need access to a
 few RPC calls.
 
 To initiate this process we'd only need a standardized protocol for
 the socket communication. Andrew said that doesn't exist and won't with
 regard to winbind. I'd like to focus the discussion in this direction.
 
  - is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?
  - is the winbind team willing to add more RPC calls to the interface?
 
 If not, Wine might do best by creating a winebind that meets these 
 requirements. That might be the best way after all, because
 incorporating the functionality needed by Windows clients into winbind
 would make no sense in environments where Wine is not running, just
 increase winbind's size unnecessarily.
 
 winebind would be linked against Samba libraries, and therefore be GPL
 from the start.
 
 Martin
 
 -- 
 Martin WilckPhone: +49 5251 8 15113
 Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
 Heinz-Nixdorf-Ring 1  mailto:[EMAIL PROTECTED]
 D-33106 Paderborn   http://www.fujitsu-siemens.com/primergy
 
 
 
 
-- 
Simo Sorce - [EMAIL PROTECTED]
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399



signature.asc
Description: This is a digitally signed message part


Re: Using winbind with Wine

2002-09-26 Thread Luke Howard


 - is the winbind team willing to standardize the protocol, or at least
   ensure backward compatibility in future versions?

Rather than inventing new protocols, why not just use DCE RPC over domain
sockets or TCP/IP?

The only catch is that you need a DCE RPC client library. We're using the
OSF DCE runtime (actually, FreeDCE), which is BSD-licensed. 

We are doing a similar thing, except in reverse, so that SAMBA can act as
a named pipe front-end to our proprietary DCE RPC services. More 
information is at http://www.padl.com/Research/XAD.html.

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com



Re: Using winbind with Wine

2002-09-26 Thread jra

On Fri, Sep 27, 2002 at 12:50:57AM +1000, Luke Howard wrote:
 
  - is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?
 
 Rather than inventing new protocols, why not just use DCE RPC over domain
 sockets or TCP/IP?
 
 The only catch is that you need a DCE RPC client library. We're using the
 OSF DCE runtime (actually, FreeDCE), which is BSD-licensed. 

Because DCE/RPC is *horrible* ? :-) :-). If you need a new
RPC protocol please use ONC/RPC/NDR not DCE :-).

Jeremy.



Re: Using winbind with Wine

2002-09-26 Thread Tim Potter

On Thu, Sep 26, 2002 at 01:47:38PM +0200, Martin Wilck wrote:

 To initiate this process we'd only need a standardized protocol for
 the socket communication. Andrew said that doesn't exist and won't with
 regard to winbind. I'd like to focus the discussion in this direction.
 
  - is the winbind team willing to standardize the protocol, or at least
ensure backward compatibility in future versions?

There is a LGPL client library (well library is probably doing it more
justice than it deserves) called wb_client.c which is used in the
NSS modules that talk to winbindd.  I would think that would be a
preferable way of talking to winbindd rather then rewriting code
to talk the winbindd protocol.

  - is the winbind team willing to add more RPC calls to the interface?

Not unless they are related to authentication or user/group enumeration.

 winebind would be linked against Samba libraries, and therefore be GPL
 from the start.

Heh - cute name.  (-:


Tim.



Re: Using winbind with Wine

2002-09-26 Thread Andrew Bartlett

Tim Potter wrote:
 
 On Thu, Sep 26, 2002 at 01:47:38PM +0200, Martin Wilck wrote:
 
  To initiate this process we'd only need a standardized protocol for
  the socket communication. Andrew said that doesn't exist and won't with
  regard to winbind. I'd like to focus the discussion in this direction.
 
   - is the winbind team willing to standardize the protocol, or at least
 ensure backward compatibility in future versions?
 
 There is a LGPL client library (well library is probably doing it more
 justice than it deserves) called wb_client.c which is used in the
 NSS modules that talk to winbindd.  I would think that would be a
 preferable way of talking to winbindd rather then rewriting code
 to talk the winbindd protocol.

The problem is that we don't ship it as a shared lib, and it still
expects the client program to fill in the winbind struct.  This is the
problem, becouse that struct changes shape regularly.

   - is the winbind team willing to add more RPC calls to the interface?
 
 Not unless they are related to authentication or user/group enumeration.

Agreed.  (However I am thinking of moving nss_wins in there soon too, to
match the IRIX code).

Andrew Bartlett

-- 
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team  [EMAIL PROTECTED]
Student Network Administrator, Hawker College   [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net



Re: Using winbind with Wine

2002-09-25 Thread Luke Howard


I started thinking about other options when I found the wbinfo -n
call. AFAIK there is no way to obtain equivalent info through PAM/NSS,
simply because these APIs have no concept of a SID. Obviously apart from
the SID there is a lot more information to gather from a PDC. I have not
digged deeply enough into this to be able to enumerate everything, but
think of the different GetUserInfo() calls on NT.

I suspect those calls on NT ultimately call into the LSA. Sounds like it
would be good if you could make RPCs to SAMBA without having to wrap them
in SMB, ie. over something equivalent to ncalrpc (aka LPC on NT).

What matters to wine is that if a call goes like this:

Windows app - wine - PAM or other API - winbind - RPC - Windows server,

we must ensure that the Unicode string wine receives from the app 
reaches the server ungarbled.

You could use UTF-8 if you are forced through C string API.

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com



Re: Using winbind with Wine

2002-09-25 Thread Richard Sharpe

On Wed, 25 Sep 2002, Rafal Szczesniak wrote:

 On Wed, Sep 25, 2002 at 03:06:05PM +0200, Martin Wilck wrote:
  Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett:
  
   As to unicode, I
   have designated one call as being in utf8, to cope with external
   interaction, so it's possible things can happen here.
  
  What matters to wine is that if a call goes like this:
  
  Windows app - wine - PAM or other API - winbind - RPC - Windows server,
  
  we must ensure that the Unicode string wine receives from the app 
  reaches the server ungarbled.
 
 Seems like you'd like to see one more library as winbind's companion.
 However, if libsmbclient is licensing stumbling block, then similar
 situation may happen with such winbind's library :(
 Besides, I'm not sure whether designing another library is ``the good
 way out''.

I do not think that libsmbclient is the right way to do this. I think that 
the correct way is to make the various Samba client RPC libaries available 
as separate DSOs so that clients can make dirrect use of what they need. 
Then the wine group can possibly build a thing DLL wrapper around the 
underlying RPC libraries.

Regards
-
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED]




Re: Using winbind with Wine

2002-09-24 Thread Andrew Bartlett

Martin Wilck wrote:
 
 Hello,
 
 There has been a discussion on wine-devel about using winbind
 for purposes like user authorization, retrieving user and group
 information, and more.
 
 It seemed reasonable to use PAM and NSS for the basic lookups and
 leave it to the sysadmin to configure these services to use winbind.
 
 Winbind offers some more functionality than that, though, such as
 SID lookups.
 
 Continuing along that line, it would be desirable to have a more generic
 interface than what winbindd currently offers - actually it would be
 nice to be able to access all RPC calls that samba supports through an
 interface like winbindd's.
 
 * Are there any plans by the Samba team to extend winbindd in this
 direction?
 
 * If no, would the Samba team accept patches from wine developers
 implementing such extensions to winbindd?
 
 * Does winbind support client requests (from the Unix side) where
 strings are in Unicode format, i.e. could wine pass Unicode strings from
 Windows applications to windbind directly?
 
 * If no, would it be possible to extend winbindd to support this without
 modifying the samba libraries?

Firstly, it's good to see that winbind is starting to get some interest
:-) I've been working closely with the squid folk on their integration
with winbind, and will certainly do what I can to help out Wine too.

Secondly, don't fall into the trap squid (with my encouragement I might
add...) fell into - don't use the winbind pipe directly.  The winbind
API is an internal Samba API, and can change without warning.

I'm not sure however on 'allow access to all RPCs' - what exactly are
you trying to do here?  Winbindd exists in its current form to provide
some NT services to unix, it's not really a general-purpose lib.  For
one, it doesn't have the user's security context etc.  As to unicode, I
have designated one call as being in utf8, to cope with external
interaction, so it's possible things can happen here.

However, we really need to know what you are trying to do...

Andrew Bartlett
-- 
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team  [EMAIL PROTECTED]
Student Network Administrator, Hawker College   [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net