samba pipe?

Andrew Tridgell tridge at
Wed Feb 16 15:04:06 GMT 2005


yes, I think the basic idea is good

 > The idea is to have the homedir and shell either fixed UTF-8
 > encoded or create a separate call to tell the server about the
 > client's locale.

definately use a fixed charset. Either UTF16 or UTF8.

 > 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 for other pipes anyway.

Exposing information about users unnecessarily is a bad idea. I don't
want to expose an interface that tells all anonymous clients what
accounts have restricted shells and what don't.

Now some minor IDL nit-picking:

 > 	NTSTATUS samba_SidToUid (
 > 	    [in]	dom_sid *sid,
 > 	    [out]	uint32 uid
 > 	    );

the first parameter should be either a ref pointer or should not be a
pointer. When you put a [in] pointer in IDL it means "this could be
NULL". What would it mean for this call to get a NULL ptr for the sid?

While the server could do something like:

  if (r->in.sid == NULL) return NT_STATUS_INVALID_PARAMETER;

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

Next, what about systems with uids larger than 32 bits? I'd suggest
using a hyper now, so that if two systems with large uid_t are talking
to each other we don't lose information.

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 based 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 useful interface.

Cheers, Tridge

More information about the samba-technical mailing list