Am Die, 2002-09-17 um 20.48 schrieb Mike McCormack:
Did you get my other mails? I'll include the text again... they don't seem to have made it to wine-devel, so I'm wondering if they got anywhere at all...
No they didn't, at least not to me. Thanks for resending...
BTW. The PAM module you are talking about was a goal of Samba TNG.
"Was" - does that mean the project is dead? I reckon that the "winbind" module of the current Samba release is pretty close to what we want in terms of host, user, and group lookup.
I think that can be done with a NetBIOS QUERY packet with "*" as the name to query. You'll then get every machine on your local network sending a QUERY RESPONSE packet back to you with the machine's name.
The operation is similar to the code to resolve a NetBIOS name (see NB_Lookup in files/smb.c)
I need yet to understand how all these things relate. Winsock may use NetBIOS as a service provider, but NetBIOS seems to offer an independent interface to other APIs as well, right? If I understand you right, the Netbios stuff is then located somewhere in kernel32. Is the winsock provider an independent package or part of the NetBIOS core?
The named pipes code needs to be rewritten to work through SMB so that we can support DCOM clients (computer to computer). Supporting a DCOM server is a problem because Samba is usually in the way on the ports we need to listen to... it would be nice to have some way for Samba and Wine to work together... a Netbios kernel module perhaps?
IMO this raises more fundamental questions about the role wine should play. Samba is a service offered by the Unix system on which wine is running. If wine were to grab the NetBIOS ports, it would take over this service functionality; I doubt that's a good approach. Wine could perhaps offer services on an IP alias instead, somewhat similar as described in http://www.deschner.de/gd/dual_samba.html
shell32 manages passwords and shares through MPR.DLL. We need to add some code to show the Network Neighbourhood icon and probe any connected shares, connect new shares, etc to shell32.
If you need something specific, I'll see what I can do, but a full implementation is probably a bit much for this weekend ;-)
I think it needs to be clarified what we're actually heading for. As I said, I consider it potentially dangerous if wine offers services on the network bypassing the ordinary Unix security mechanism. Acting as a client is a different story, I guess we want maximum functionality in that area.
When it comes to User authentication, I am strongly for wine communicating with the Unix system (e.g. PAM). Then if PAM supports NT domain authentication (through samba or whatever), Active directory AKA LDAP authentication, etc., wine would, too. We'd just have to ensure that we don't loose too much on our way through the Unix layer.
Martin
Hi Martin,
I need yet to understand how all these things relate. Winsock may use NetBIOS as a service provider, but NetBIOS seems to offer an independent interface to other APIs as well, right? If I understand you right, the Netbios stuff is then located somewhere in kernel32. Is the winsock provider an independent package or part of the NetBIOS core?
Yes, I believe that the NetBIOS implementation is a kernel driver in Windows.
The named pipes code needs to be rewritten to work through SMB so that we can support DCOM clients (computer to computer). Supporting a DCOM server is a problem because Samba is usually in the way on the ports we need to listen to... it would be nice to have some way for Samba and Wine to work together... a Netbios kernel module perhaps?
IMO this raises more fundamental questions about the role wine should play. Samba is a service offered by the Unix system on which wine is running. If wine were to grab the NetBIOS ports, it would take over this service functionality; I doubt that's a good approach. Wine could perhaps offer services on an IP alias instead, somewhat similar as described in http://www.deschner.de/gd/dual_samba.html
Well, that's exactly what I want to avoid. NetBIOS multiplexes many NetBIOS "ports" through a single TCP/IP port. It can also use SPX/IPX as it's underlying protocol.
If Samba were written the right way, it would be possible to share TCP/IP port 139 with Wine via a unix domain socket, so that applications running under Wine (eg. MS Hearts) could participate on the Windows network alongside Samba.
I think it needs to be clarified what we're actually heading for. As I said, I consider it potentially dangerous if wine offers services on the network bypassing the ordinary Unix security mechanism. Acting as a client is a different story, I guess we want maximum functionality in that area.
Well, at least I would like to have full NetBIOS client functionality; access to file shares without mounting them on the UNIX VFS, access to Named Pipe endpoints on other machines, the ability to browse Network shares, etc.
That would be a good starting point. If we could then go onto supporting applications that listen for NetBIOS requests, that would be good too.
When it comes to User authentication, I am strongly for wine communicating with the Unix system (e.g. PAM). Then if PAM supports NT domain authentication (through samba or whatever), Active directory AKA LDAP authentication, etc., wine would, too. We'd just have to ensure that we don't loose too much on our way through the Unix layer.
Yes, integration is what makes Wine good, so I agree with you here.
Martin
Mike
Am Die, 2002-09-17 um 22.08 schrieb Mike McCormack:
service functionality; I doubt that's a good approach. Wine could perhaps offer services on an IP alias instead, somewhat similar as described in http://www.deschner.de/gd/dual_samba.html
Well, that's exactly what I want to avoid. NetBIOS multiplexes many NetBIOS "ports" through a single TCP/IP port. It can also use SPX/IPX as it's underlying protocol.
What's wrong with an IP alias? If NetBIOS multiplexing requires hacking Samba, getting there will require substantial support from the Samba community at take an indeterminate amount of time. Setting up IP aliasing, on the other hand, is a simple administration task that requires no support by third parties. Thus server functionality will be much easier to achieve this way then the other (even if the Samba guys cooperate, it will take years until a majority of the Samba/wine installations has the modified Samba).
When it comes to User authentication, I am strongly for wine communicating with the Unix system (e.g. PAM). Then if PAM supports NT domain authentication (through samba or whatever), Activedirectory AKA LDAP authentication, etc., wine would, too. We'd just have to ensure that we don't loose too much on our way through the Unix layer.
Yes, integration is what makes Wine good, so I agree with you here.
I just played around with winbind a bit, and I'd say it's exactly what we're looking for. Change a few lines in nsswitch.conf, add pam_winbind.so to your PAM configuration, and you're all set.
Martin
-
Martin Wilck -
Mike McCormack