[proof of concept] libwbclient.so

[Danilo Almeida]

Jerry wrote:

> One alternative that Danilo (at work) suggested is just

Some additional suggestions...

1) For the status codes, use WBC_STATUS_ as a prefix instead of just WBC_.  This keeps the namespace cleaner.

2) Why is enum wbcSidType using WBC_SID_NAME_... instead of WBC_SID_TYPE_?

3) Why not have full consistency wrt to typedefs and have all the types typedefed with _wbc -> wbc?  This also implies domain_sid -> wbcDomainSid and domain_info -> wbcDomainInfo.

4) We should probably have a proposed versioning solution different that using library versions.  Consider these scenario where some important app uses libfoo and libbar.  In addition, there is a wbclient v1 where a wbcLogin call takes a list of SIDs and a v2 where a wbcLogin takes a list of names.  libfoo uses wbclient v1 and libbar uses wbclient v2...  Now we could get symbols conflicts in the app.  I would like a solution to be documented to version the API such that we can have an interim period where winbind ships with a v1 and v2 API and an app can link against libs that might be using different API versions.

James wrote:

> looks pretty good, a few comments:
>     - hardcode MAXSUBAUTHS to avoid binary compatibility issues if you
>       hit a preprocessor conflict

I suggest using WDC_MAXSUBAUTHS.

James wrote:

>     - use the wbc prefix for the new structures and types

+1

James wrote:

>     - wbcErrorString() should return const char *

+1

Simo wrote:

> Why do we ever need to understand SIDs on the pam side anyway?

As someone who has worked a lot on the PAM (and LAM) side, I sympathize completely.  However, the first goal should be to abstract out the winbind pipe interface.  Making any additional changes to the interface would come afterwards, in my opinion.

- Danilo