librpc/ndr use hyper for uid_t/gid_t rather than udlong
simo at samba.org
Thu Mar 10 06:19:59 MST 2011
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
> 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.
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical