[Libguestfs] [PATCH nbdkit v2 3/3] ocaml: Add bindings for nbdkit_peer_{pid, uid, gid}.

Daniel P. Berrangé berrange at redhat.com
Mon Oct 5 13:52:20 UTC 2020


On Mon, Oct 05, 2020 at 08:39:41AM -0500, Eric Blake wrote:
> On 10/3/20 1:50 PM, Richard W.M. Jones wrote:
> > ---
> >  plugins/ocaml/NBDKit.mli |  7 +++++++
> >  plugins/ocaml/NBDKit.ml  |  4 ++++
> >  plugins/ocaml/bindings.c | 24 ++++++++++++++++++++++++
> >  3 files changed, 35 insertions(+)
> > 
> > diff --git a/plugins/ocaml/NBDKit.mli b/plugins/ocaml/NBDKit.mli
> > index ececd5fd..8abfeb49 100644
> > --- a/plugins/ocaml/NBDKit.mli
> > +++ b/plugins/ocaml/NBDKit.mli
> > @@ -162,3 +162,10 @@ val shutdown : unit -> unit
> >  
> >  (** Print a debug message when nbdkit is in verbose mode. *)
> >  val debug : ('a, unit, string, unit) format4 -> 'a
> > +
> > +(** Binding for [nbdkit_peer_pid]. *)
> > +val peer_pid : unit -> int
> > +(** Binding for [nbdkit_peer_uid]. *)
> > +val peer_uid : unit -> int
> > +(** Binding for [nbdkit_peer_gid]. *)
> > +val peer_gid : unit -> int
> 
> Is int sufficient on 32-bit platforms, or do you need int32?  But on
> 64-bit platforms, I don't see a system ever having enough valid
> uid_t/gid_t/pid_t to overflow int to the point that int64 would have
> been better.

We shouldn't assume that IDs are allocated sequentially, they might
be sparsely allocated. eg with containers and user namespaces, ranges
of UIDs/GIDs are reserved for specific users / containers to utilize.
eg on Fedora, my user account is reserved 65536  UIDs, starting at
an offset of 100000.

So it is entirely conceivable there could be a system which has very
few UIDs/GIDs/PIDs in use, but none the less has some allocated from
a range that is larger than INT32MAX

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the Libguestfs mailing list