Am Fre, 2002-09-20 um 21.25 schrieb Andriy Palamarchuk:
I played a couple of days with PAM (Pluggable Authentication Modules). I do not have big experience in this area and want to know your opinion about my ideas.
*** PAM and Wine ***
Integration with PAM allows Wine to provide authentication services for Windows applications through Windows API. PAM has modules for native Unix authentication, Samba, flat files, relational databases.
Did you have a look at the LogonUser() implementation I submitted last week?
Questions, problems:
Do we have requirement for wineserver to work across user boundaries?
I think we'll ultimately have to, although that's certainly a long-term-future project. wineserver and the ntdll would need to have a concept of security tokens etc., and we would need to figure out a way to e.g. change personality with CreateProcessAsUser() without compromising underlying Unix security.
AFAICT, this would mean substantial additions to the core of wine, and must be done very carefully. For CreateProcessAsUser(), for example, wine would need to have the CAP_SETUID capability, although we certainly don't want to run wine with root privileges.
If no, then we probably don't need PAM service for Wine itself.
As you see Wine won't know anything about NT domains. I was thinking about passing service name through domain name parameter.
I strongly disagree. I think the domain should be the domain, and nothing else.
This is the approach in my LogonUser() implementation ("user", "domain") -> "domain\user", and do Samba authentication with that user name.
This is also the syntax you use when authorizing yourself with smbclient or smbmount in large NT networks with several domains.
The beautiful aspect of this is that the pam_winbind module authenticates against a Windows PDC for you, which is what the Windows application expects.
Call LogonUser accepts lpszDomain parameter. Instead of the domain name DOMAIN1 user provides to the application PAM service name SERVICE1. PAM service SERVICE1 is configured to use Samba module for authentication in NT domain DOMAIN1.
I think it would be more reasonable to put a "pam servicename" entry into the registry for each application that uses authentification. If there is none, we'd use the standard "wine" service, and if that doesn't exist either, PAM would automatically use "other" which is usually very restricted.
PAM provides authorization and nothing else. To get more information from the authorization provider you should access it directly. E.g. with PAM only it is impossible to get list of users, groups from Windows NT domain, which user belongs to which group. Even more, it is impossible to know that some PAM service underneath uses NT domain and name of this domain.
But you can do these things with nss switch. With windbind properly configured, getpwnam() and friends will work with the PDC through winbind.
The whole picture looks like this:
For authentification, account and session setup: wine -> PAM -> pam_winbind -> winbindd -> PDC
For user/group info: wine -> NSS switch -> nss_winbind -> winbindd -> PDC
I can't imagine how to implement with PAM scenario like this - Windows application gets list of users belonging to some group, presents it to the user, then does authentication for one of user names. On other hand it is possible to do that with Samba.
PAM must use samba, that's the point.
The main reason to use PAM is that wine should not (I am positive about that) work around the "native" Unix authorization mechanisms that PAM provides.
It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine.
No, please - let's not reinvent the wheel!
The downside - this is much more complex approach than PAM.
Exactly.
I think what causes confusion is that PAM only covers part of what belongs into "security management" in NT. It's main functionality is to provide a transparent authentication mechanism.
However, it does this job very well, and it can easily be complemented by other components (see above) to do the rest.
Martin