Username mapping

Jeremy Allison jallison at
Fri Jun 5 23:05:38 GMT 1998

Jean-Francois Micouleau wrote:

> In the original mail, Kevin said the trouble is with a username longer
> than 8 chars in /etc/passwd.
> So I suspect somewhere samba truncate the username to 8 chars before doing
> the compare against /etc/passwd.
> BTW, this re-open the thread about OS supporting username longer than 8
> chars for trust accounts, as it looks like linux (redhat 4.2) support it

I'm really glad you brought this up again. In the current
CVS tree the mappings between uid/gid and rid are done
by shifting left by 3 bits and adding 1000 (as we worked
out with Mark from OpenNT).

Now the reason we have to do the 3 bit shift is due to
the different NT account types we need to keep track of.

We need the mapping to be a static function as in ACL
code we need to distinguish between NT account types
(only users and groups should be valid).

The problem it causes is that rids need to be kept below
24 bits.

My suggestion is that, if we keep machine accounts and
trust accounts as valid unix users in the unix /etc/passwd
file, as well as the current valid unix users (so we know
there's no mapping conflict with uids), then we can reduce
the 3 bit shift to a 1 bit shift, as all we ever will need
to differentiate in the ACL code is users and groups.

All other use of rids is explicit in the particular
RPC call - thus allowing a much greater mapping range
for users and groups.

Thoughts anyone (I could do this easily, just change
the #defines RID_MASK and RID_MULTIPLIER from 3 and
8 to 1 and 2 respectively, the same code would work
fine) ?


Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba-technical mailing list