RFC: Wine and PAM integration

[Martin Wilck]

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

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