libwbclient - wbcLogoffUser() & wbcLookupDomainController

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Metze,

Here's what I'm proposing for the two calls discussed on IRC

1. wbcErr wbcLogoffUser(const char *username,
                         const char *ccfilename);

Some explanations.  There is no current LogonUser pipe call.
This is implicit in the Authenticate call.  So I've not added
a wbcLogonUser().  I debated dropping the cred cache pathood
and having the library look up the default. This might still
be a good idea to help relieve the burden on the application
developer.  But it can bet set to NULL to it's not that bad.


2.  wbcErr wbcLookupDomainController(const char *domain,
                                struct wbcDomainControllerInfo *dc_info);


Here's we currently only return the char* name of the DC
but I expect that other information would be useful.
Looking at the this from netlogon.h, I think something similar
would be a good idea as an info structure.  At least the
name, address, and site information.

struct netr_DsRGetDCNameInfo {
        const char *dc_unc;/* [unique,charset(UTF16)] */
        const char *dc_address;/* [unique,charset(UTF16)] */
        enum netr_DsRGetDCNameInfo_AddressType dc_address_type;
        struct GUID domain_guid;
        const char *domain_name;/* [unique,charset(UTF16)] */
        const char *forest_name;/* [unique,charset(UTF16)] */
        uint32_t dc_flags;
        const char *dc_site_name;/* [unique,charset(UTF16)] */
        const char *client_site_name;/* [unique,charset(UTF16)] */
}/* [public] */;

Comments?





cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIH2xBIR7qMdg1EfYRAjnbAKDDSi2H4QNPMoV7ZySDLsBGCrhVXQCfa6ac
gnTbPxoJQQ0vTOJqxJ3ZZoo=
=ZplL
-----END PGP SIGNATURE-----

[Karolin Seeger]

Jerry,

On Mon, May 05, 2008 at 03:21:21PM -0500, Gerald (Jerry) Carter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Metze,
>
> Here's what I'm proposing for the two calls discussed on IRC
>
> 1. wbcErr wbcLogoffUser(const char *username,
>                          const char *ccfilename);
>
> Some explanations.  There is no current LogonUser pipe call.
> This is implicit in the Authenticate call.  So I've not added
> a wbcLogonUser().  I debated dropping the cred cache pathood
> and having the library look up the default. This might still
> be a good idea to help relieve the burden on the application
> developer.  But it can bet set to NULL to it's not that bad.
>
>
> 2.  wbcErr wbcLookupDomainController(const char *domain,
>                                 struct wbcDomainControllerInfo *dc_info);
>
>
> Here's we currently only return the char* name of the DC
> but I expect that other information would be useful.
> Looking at the this from netlogon.h, I think something similar
> would be a good idea as an info structure.  At least the
> name, address, and site information.
>
> struct netr_DsRGetDCNameInfo {
>         const char *dc_unc;/* [unique,charset(UTF16)] */
>         const char *dc_address;/* [unique,charset(UTF16)] */
>         enum netr_DsRGetDCNameInfo_AddressType dc_address_type;
>         struct GUID domain_guid;
>         const char *domain_name;/* [unique,charset(UTF16)] */
>         const char *forest_name;/* [unique,charset(UTF16)] */
>         uint32_t dc_flags;
>         const char *dc_site_name;/* [unique,charset(UTF16)] */
>         const char *client_site_name;/* [unique,charset(UTF16)] */
> }/* [public] */;
>
> Comments?

 

We (Volker, Metze, Günther, Michael and me) talked about these two functions
again. Maybe we should try to get them into 3.2.0 to avoid bumping the
library version number in 3.2.1.

Is it possible to finish them until May 21? If yes, I would propose to
pick it for 3.2.0rc1. Do you agree?

Cheers,
Karolin

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: [phone], fax: [phone]
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karolin Seeger wrote:
| Jerry,

| We (Volker, Metze, Günther, Michael and me) talked
| about these two functions again. Maybe we should try
| to get them into 3.2.0 to avoid bumping the library
| version number in 3.2.1.
|
| Is it possible to finish them until May 21? If yes,
| I would propose to pick it for 3.2.0rc1. Do you agree?

Sure.  Sounds good to me.  I wrote them up yesterday but
need to finish testing.  I should be able to have them
in the tree in the next few days.  I'll post patches
once my local test pass.







cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIEE9IR7qMdg1EfYRAhPxAJ48QkaE7+dmmyJ0iQiSmQf8Le8miACgxTgF
1dhVRe51uKSVNknru62aqbk=
=/Pp0
-----END PGP SIGNATURE-----

[Stefan (metze) Metzmacher]

Hi Jerry,

here're some comments about the design of the new calls.
However see also my next mail about deferring all this...

> 1. wbcErr wbcLogoffUser(const char *username,
>                          const char *ccfilename);
>
> Some explanations.  There is no current LogonUser pipe call.
> This is implicit in the Authenticate call.  So I've not added
> a wbcLogonUser().

This is not true, wbcAuthenticateUserEx() doesn't provide the ability
to handle local logons as needed by pam_winbind and it should not.

I think we should have a wbcLogonUser() and pam_winbind should be able
to use it later (in v3-3).

I'm not yet sure about the prototype of wbcLogonUser()...
...but I think we should use arrays of a structure like this:

struct {
        const char *name;
        bool critical;
        struct {
                uint32_t length;
                uint8_t *data;
        } value;
}

to pass extra data, e.g. needed for AFS krb5 logons in and out
of wbcLogonUser().

>  I debated dropping the cred cache pathood
> and having the library look up the default. This might still
> be a good idea to help relieve the burden on the application
> developer.  But it can bet set to NULL to it's not that bad.

I think the wbcLogoffUser() call should also get the uid.

I think we can skip the ccache filename, as it's produced by the LOGON
call, so winbind should be able to reproduce it.

>
> 2.  wbcErr wbcLookupDomainController(const char *domain,
>                                 struct wbcDomainControllerInfo *dc_info);
>
>
> Comments?

Something like this looks good, but maybe we need an uint32_t flags as
input? Günther, you may have some additional comments here? Maybe we
should return the same as what we will store in gencache...

metze

[Stefan (metze) Metzmacher]

Hi,

> We (Volker, Metze, Günther, Michael and me) talked about these two functions
> again. Maybe we should try to get them into 3.2.0 to avoid bumping the
> library version number in 3.2.1.

I thought about all this a bit more and noticed that we would also need
to implement a wbcChangePassword() in order to later support pam_winbind
and ntlm_auth.

And as my last mail explained we also need wbcLogonUser() and have it
complete so that pam_winbind can use it later.

We should aim to get as much done before 3.2.0.rc1, but it could be that
we find some other missing features, which require
an update of the library version.

Maybe we should think about using symbol versioning,
see http://people.redhat.com/~drepper/symbol-versioning.

That would mean we can extent the API without breaking old applications.

And at least rpm based systems would be able to handle this easily, e.g.

metze@SERNOX:~> rpm -q --provides libattr
libattr.so.1
libattr.so.1(ATTR_1.0)
libattr.so.1(ATTR_1.1)
libattr.so.1(ATTR_1.2)
libattr.so.1(libattr.so.1)
libattr = 2.4.28-38

metze@SERNOX:~> rpm -q --requires attr
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libattr.so.1
libattr.so.1(ATTR_1.0)
libattr.so.1(ATTR_1.2)
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.3)
libc.so.6(GLIBC_2.3.4)
rpmlib(PayloadIsBzip2) <= 3.0.5-1

Does anyone knows if debian also supports dependencies based
on the different symbol versions within a shared library.

The patch is really trivial, but we need to make sure it doesn't
break the build on some systems:

diff --git a/source/exports/libwbclient.syms
b/source/exports/libwbclient.syms
index f1e68b4..8c12c1a 100644
--- a/source/exports/libwbclient.syms
+++ b/source/exports/libwbclient.syms
@@ -1,4 +1,4 @@
-{
+WBC_0.1 {
        global: wbc*;
        local: *;
 };

metze

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan (metze) Metzmacher wrote:

> Hi Jerry,
>
> here're some comments about the design of the new calls.
> However see also my next mail about deferring all this...
>
>> 1. wbcErr wbcLogoffUser(const char *username,
>>                          const char *ccfilename);
>>
>> Some explanations.  There is no current LogonUser pipe call.
>> This is implicit in the Authenticate call.  So I've not added
>> a wbcLogonUser().
>
> This is not true, wbcAuthenticateUserEx() doesn't provide
> the ability to handle local logons as needed by pam_winbind
> and it should not.
>
> I think we should have a wbcLogonUser() and pam_winbind
> should be able to use it later (in v3-3).

So you think wbcLogonUser() should be the equivalent of
pam_sm_open_session()?  That is currently a no-op in pam_winbind.c.
Also see my follow up question below.

>
> I'm not yet sure about the prototype of wbcLogonUser()...
> ...but I think we should use arrays of a structure like this:
>
> struct {
> const char *name;
> bool critical;
> struct {
> uint32_t length;
> uint8_t *data;
> } value;
> }
>
> to pass extra data, e.g. needed for AFS krb5 logons in and out
> of wbcLogonUser().

I'm not quite following you.  What extra data are you passing?


>>  I debated dropping the cred cache pathood
>> and having the library look up the default. This might still
>> be a good idea to help relieve the burden on the application
>> developer.  But it can bet set to NULL to it's not that bad.
>
> I think the wbcLogoffUser() call should also get the uid.

Internally the cal gets the uid from getpwnam().  I just
don't think.  The calling application should have to do that.

> I think we can skip the ccache filename, as it's produced
> by the LOGON call, so winbind should be able to reproduce it.

The current winbindd_pam.c code relies upon having the
cache location to remove it.

>
>> 2.  wbcErr wbcLookupDomainController(const char *domain,
>>                struct wbcDomainControllerInfo *dc_info);
>>
>>
>> Comments?
>
> Something like this looks good, but maybe we need
> an uint32_t flags as input? Günther, you may have
> some additional comments here? Maybe we should return
> the same as what we will store in gencache...

So add a uint32_t flags field marked as "reserved for future
use"?  Right now the winbindd pipe call only returns the
DC name.  That can change of course for v3-3.






cheers, jerry
- --
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIjZTIR7qMdg1EfYRAuToAJ97u2tEdasJHK3/wWRwJwsxQfs4WgCcCBkx
YNdoqBw2qMW4+p4aki+sslw=
=ntQd
-----END PGP SIGNATURE-----

[Volker Lendecke]

On Wed, May 07, 2008 at 06:08:03PM -0500, Gerald (Jerry) Carter wrote:

> > I'm not yet sure about the prototype of wbcLogonUser()...
> > ...but I think we should use arrays of a structure like this:
> >
> > struct {
> > const char *name;
> > bool critical;
> > struct {
> > uint32_t length;
> > uint8_t *data;
> > } value;
> > }
> >
> > to pass extra data, e.g. needed for AFS krb5 logons in and out
> > of wbcLogonUser().
>
> I'm not quite following you.  What extra data are you passing?

The same info that wbinfo -k transfers: An AFS-style krb4
ticket that was created using the fake-kaserver facility by
winbind. Others might want to add other kinds of token.

Volker

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Volker Lendecke wrote:

> On Wed, May 07, 2008 at 06:08:03PM -0500, Gerald (Jerry) Carter wrote:
>>> I'm not yet sure about the prototype of wbcLogonUser()...
>>> ...but I think we should use arrays of a structure like this:
>>>
>>> struct {
>>> const char *name;
>>> bool critical;
>>> struct {
>>> uint32_t length;
>>> uint8_t *data;
>>> } value;
>>> }
>>>
>>> to pass extra data, e.g. needed for AFS krb5 logons in and out
>>> of wbcLogonUser().
>> I'm not quite following you.  What extra data are you passing?
>
> The same info that wbinfo -k transfers: An AFS-style krb4
> ticket that was created using the fake-kaserver facility by
> winbind. Others might want to add other kinds of token.

ok.  I'll have to look at that some more today and come back.





cheers, jerry
- --
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIxv6IR7qMdg1EfYRAjZ8AKDIUIXbMsohmPD5v0z06ujk0+vudgCgtBW1
DxCmZhaMEQ26nQ/bxtNoIY4=
=cILC
-----END PGP SIGNATURE-----

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan (metze) Metzmacher wrote:

>
> We should aim to get as much done before 3.2.0.rc1, but it
> could be that we find some other missing features, which require
> an update of the library version.
>
> Maybe we should think about using symbol versioning,
> see http://people.redhat.com/~drepper/symbol-versioning.
>
> That would mean we can extent the API without breaking
> old applications.

I read up on this it makes sense to me.  But I'm not sure
how this would help in the cases where we aren't using GNU ld.
We would still have the same library versioning issues right ?

> diff --git a/source/exports/libwbclient.syms
> b/source/exports/libwbclient.syms
> index f1e68b4..8c12c1a 100644
> --- a/source/exports/libwbclient.syms
> +++ b/source/exports/libwbclient.syms
> @@ -1,4 +1,4 @@
> -{
> +WBC_0.1 {
>         global: wbc*;
>         local: *;
>  };

cheers, jerry
- --
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKaRrIR7qMdg1EfYRAmVuAKCKn2sIYi2T8hcBD9mZM3gDNaWtbwCgyZ1d
uVoH+Mrxl2jZVaW+0h0wIhk=
=Rd6A
-----END PGP SIGNATURE-----

[Stefan (metze) Metzmacher]

Gerald (Jerry) Carter schrieb:

> Stefan (metze) Metzmacher wrote:
>> We should aim to get as much done before 3.2.0.rc1, but it
>> could be that we find some other missing features, which require
>> an update of the library version.
>
>> Maybe we should think about using symbol versioning,
>> see http://people.redhat.com/~drepper/symbol-versioning.
>
>> That would mean we can extent the API without breaking
>> old applications.
>
> I read up on this it makes sense to me.  But I'm not sure
> how this would help in the cases where we aren't using GNU ld.
> We would still have the same library versioning issues right ?
>

I fear so...

However we could provide mutliple .so files, where the newer ones
link in the older ones. But I'm not sure if this has also problems...

metze

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Metze,

> However we could provide mutliple .so files, where the
> newer ones link in the older ones. But I'm not sure
> if this has also problems...

I think this is better solved in the Makefile.  We simply
maintain an older API wrapper layer that calls into new
code.  So we physically build the libwbclient.so.0 and
libwbclient.so.1 (at some point in the future) but there is
a lot of shared code between them.

I'm happy having to deal with that bridge when we get there.
For now, I think the building process and versioning is usuablefor the first
public release.

Do you agree?



cheers, jerry
- --
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKasxIR7qMdg1EfYRAgeZAKDFe9iKdg5aBXPU7dkOZ67E4n5yFgCfe4fg
UTXrZn+0kQlkB++rXpFfG38=
=E86Y
-----END PGP SIGNATURE-----

[simo-7]

On Tue, 2008-05-13 at 09:23 -0500, Gerald (Jerry) Carter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stefan (metze) Metzmacher wrote:
> >
> > We should aim to get as much done before 3.2.0.rc1, but it
> > could be that we find some other missing features, which require
> > an update of the library version.
> >
> > Maybe we should think about using symbol versioning,
> > see http://people.redhat.com/~drepper/symbol-versioning.
> >
> > That would mean we can extent the API without breaking
> > old applications.
>
> I read up on this it makes sense to me.  But I'm not sure
> how this would help in the cases where we aren't using GNU ld.
> We would still have the same library versioning issues right ?

I love symbol versioning too, it is really much better than version
libraries. But it works only on Linux systems afaik.

We will need ifdefs and different code for other arches.
But if we can manage to do it, it will be MUCH better for Linux.

Simo.

--
Simo Sorce
Samba Team GPL Compliance Officer <simo@...>
Senior Software Engineer at Red Hat Inc. <ssorce@...>