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