[proof of concept] libwbclient.so

[simo]

On Tue, 2007-09-04 at 12:34 -0500, Gerald (Jerry) Carter wrote:
> 
> The entire reason for PAM is to allow an administrator the
> ability to define policy.  but you are not willing to allow
> a PAM developer to use define their own policy.

Why mixing admins and developers here?

I agree that PAM is a mechanism to allow the administrator to define the
policy. Moving this into winbindd will not change that, it may, at most,
but not necessarily, change the way you configure it.

> > There is instead a difference on performance and control. If 
> > you put the decision in winbindd you can have less round-trips
> > and less information going around, you can also have more
> > control in winbindd as talking with a daemon is much easier
> > then talking to config files/libraries (delegation,
> > automation, etc...).
> 
> This is about the same as the argument to not support kernel
> modules.  Or run time linking.  Show me numbers.  Prove to
> me that the performance issues you are championing are real
> in practice and make a difference.

I will try to come up with numbers about "require-membership-of", which
is a pretty good candidate to show real impact on performances if used
with multiple groups.

> > Also, after experience with other ugly pam/nss modules, I am 
> > a firm believer that the less you put in the user's
> > process space the better.
> 
> Again I"ll refer to "winbind use default domain" and mention
> that all of that could have been fixed in the PAM/NSS space.

If you can do that in the PAM/NSS space you can do the same in winbindd,
it's just that we didn't do a good job of separating layers and
functions when we implemented that feature, at least this is my opinion.

> Sorry, but it appears that you and I will just not agree.
> So I'll just continue working on my own patch and we'll
> take a vote when it's done.

Yup, no problem.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org