librpc/ndr use hyper for uid_t/gid_t rather than udlong

[simo]

On Thu, 2011-03-10 at 07:53 +1100, Andrew Bartlett wrote:
> On Wed, 2011-03-09 at 08:13 -0500, simo wrote:
> > On Wed, 2011-03-09 at 09:04 +0100, Andrew Bartlett wrote:
> > > The branch, master has been updated
> > >        via  9728b5a librpc/ndr use hyper for uid_t/gid_t rather than udlong
> > >       from  c4b52fb s3: Use talloc_tos() in idmap_nss_sids_to_unixids
> > > 
> > > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> > > 
> > > 
> > > - Log -----------------------------------------------------------------
> > > commit 9728b5a0d5a5c09615a09a97bf217bcacb773579
> > > Author: Andrew Bartlett <abartlet at samba.org>
> > > Date:   Wed Mar 2 19:06:15 2011 +1100
> > > 
> > >     librpc/ndr use hyper for uid_t/gid_t rather than udlong
> > >     
> > >     This has 8 byte alignment, which is what was specified in pidl for
> > >     these types.
> > 
> > I am puzzled, uid_t and gid_t are 32 bit quantitiers on all platforms I
> > know, do you know of platforms that use 64 bit uid/gid types ?
> > 
> > If not, why do you use a 64 bit type for them ?
> > 
> > Also uid_t and gid_t are signed in many platforms while here you seem to
> > be casting to uint64_t, and that doesn't look right to me.
> 
> I chose 64 bit because I didn't see a benefit in baking into stone a 32
> bit assumption that might not hold into the future, if this was ever
> used on a real (ie, not internal) protocol.

Not sure I get it, currently 32bit is the uid/gid size, I've heard all
sorts of rumors, including proposals for 128bit ids, which wouldn't fit
into a 64bit number, so I am not sure how a uint64_t would be future
proof.

>   I originally chose signed,
> but unsigned because after talking with tridge, we thought that uid_t
> was always unsigned.  

SUS isn't really clear indeed, this is all it really says afaict:

        3.428 User ID
        A non-negative integer that is used to identify a system user.
        When the identity of a user is associated with a process, a user
        ID value is referred to as a real user ID, an effective user ID,
        or a saved set-user-ID.


> Do you have a counter-example I should be aware of?  I'm happy to change
> this (again) if required. 

I checked Solaris and seem they recently standardized on uint32_t, just
like Linux, although they reserve the (ex)negative space for their
ephemeral ids concept, at least when using ZFS.

I guess the main issue I have comes into play if 2 machines with a
different understanding of the signedness/size of the IDs start talking
to each other.

But as you just said this is only for internal use for now, so I guess
it doesn't really matter.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>