Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2005 at 02:04:06AM +1100, Andrew Tridgell wrote:
> definately use a fixed charset. Either UTF16 or UTF8.

UTF8 sounds better for my taste.

> > The idea is to have anonymous access possible for reading, updating
> > operations (allocate a new unix id) needs to be over an ntlmssp
> > authenticated bind with the domain member's machine account data.

> I don't like the idea of anonymous reading of this pipe. Why is it needed?
> The nss modules would read this via winbindd, which needs to authenticate=

> other pipes anyway.

Agreed. But doing the ntlm(2?) bind with the machine account is ok? IIRC th=
can't be done in the windows world, but I think samba could implement this
without the need for kerberos I think.

> it's much better to just not have that in the interface when it makes no
> sense. By making it ref the IDL would then say "this cannot be NULL", The
> same applies to not making it a pointer at all (either alternative is fin=


Better. But for the uid2sid I would like to use a pointer to be able to ret=
NULL in case of an error.

> Next, what about systems with uids larger than 32 bits? I'd suggest using=

> hyper now, so that if two systems with large uid_t are talking to each ot=

> we don't lose information.

What should be the semantics of this? sid2uid returns >2^32, what should the
client do? Return an error? Include another level of mapping? The whole poi=
of this pipe is to avoid this kind of mapping.
> I also suggest you think about exactly how this will be used, and whether
> doing NameToSid and GetPWNam() as well as (or instead of) the uid/gid bas=

> calls are a good idea. I'm not certain which is the better choice, you'll
> need to think carefully about common usage and which provides the most us=

> interface.

The idea is to have a Samba PDC. Member workstations running winbind should=
at all have to worry about id mapping and proper 'template homedir/shell'.
Coming from there I wanted to give the minimum necessary API to accomplish
this. Groups can completely be covered by samr calls, and all that is needed
for a complete /etc/passwd entry is the shell and homedir. Given that you h=
the id mapping correct. For this first design minimality of the API was more
important than convenience, there are enough redundant APIs around that nee=
d to
be implemented correct in all aspects.

After getting that right I can see obvious optimizations, like metze's
suggestion. Or remoting getpwent/getgrent.=20


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.5 (GNU/Linux)