Unix.getuid() int overflow

Unix.getuid() int overflow

[Markus E L]

Hi Caml-Riders,

When reading the sources of otherlibs/unix I saw that the
implementation just maps the result of getuid (and similar calls) to
ints. Remembering that (s) Ocaml has 32bit ints and (b) the Linux
kernel got changed to support 32bit UIDs some longer time ago I saw
the first beginnings of a problem.

Indeed I have create users with UIDs 2^31-1^ ... 2^31+1 and executed
this program 

  print_int (Unix.getuid ());
  print_newline();

under the respective accounts:

  # id bar
  uid=2147483647(bar) gid=2147483647 groups=2147483647
  # su bar
  $ ocaml unix.cma /tmp/x.ml
  -1

(hm ...)

  # id baz
  uid=2147483648(baz) gid=2147483648(bar) groups=2147483648(bar)
  # su baz
  su: Authentication service cannot retrieve authentication info.
  (Ignored)
  $ ocaml unix.cma /tmp/x.ml
  0

(gasp!)

  # id foo
  uid=2147483649(foo) gid=2147483649 groups=2147483649
  # su foo
  su: Authentication service cannot retrieve authentication info.
  (Ignored)
  $ ocaml unix.cma /tmp/x.ml
  1

(arrgs ...)

I could live with negative user ids, but the aliasing from 2^31 on is
certainly annoying.

Furthermore I admit that many of the system tools have problems with
user ids this large anyway: adduser silently truncates uid to 2^31-1
and su also seems to have some funny problems (as illustrated above).

Still, I find the situation unsatisfactory, esp. when one wants to
write system management tools with OCaml.

A check in the Unix library would be nice, in the long run I think
using 32bit native integers is absolutely required. 

BTW: I also had a look into the current POSIX and at the first glance
couldn't discover a constant that describes the maximum of uid_t (the
result type of getuid()). It only guaranteed to be "of integer type"
which in my eyes makes using everything smaller than long long int as
variable type for processing UIDs unportable and prone to break on
some other platform (admitted: this is not probably now, it's just
annoying that the standard doesn't give enough guarantees or at least
a constant for compile time configuration to make any decisions here).

Back to the topic: 
 
 (a) I'm just reporting this here for dicumentation.

 (b) Shall I report this as bug? And at the INRIA team: Is a reworking
     of Unix planned in the forseeable time or would interested
     parties have to it themselves? I'm just asking to avoid
     duplication of work: At the moment this is not high on my list of
     priorities anyway.

Regards -- Markus

Re: [Caml-list] Unix.getuid() int overflow

[Markus E L]

Markus E L wrote:

> Hi Caml-Riders,
>
> When reading the sources of otherlibs/unix I saw that the
> implementation just maps the result of getuid (and similar calls) to
> ints. Remembering that (s) Ocaml has 32bit ints and (b) the Linux
                                       ^^^^^
s/32/31/

Stupid typo.

Regards -- Markus

[Caml-list] int overflow and Marshal failure

[Mathias Kende]

Le jeudi 30 août 2007 à 23:47 +0200, Markus E L a écrit :
> A check in the Unix library would be nice, in the long run I think
> using 32bit native integers is absolutely required. 

I had the same sort of problem with the Unix.stat function and the
st_size member being an int while it is a 64 bits int on recent systems
(including some 32 bits one). The maximum size that can be stored on 32
bits system, 1Go, is much too small for this function.

This lean me to an other, different but related, problem : marshaling a
value which contain an int on a 64 bits computer and then unmarshaling
it  on a 32 bits computer will raise an exception (Failure "input_value:
integer too large") if an int where bigger than max_int. while the
manual states than : "The format for the byte sequences is compatible
across all machines for a given version of Objective Caml."

Even if raising an exception is a "good" behaviour, it is still
impossible to read back the data and I think that there should be a way
to read back the data even in this case.

Mathias

Re: [Caml-list] int overflow and Marshal failure

[Eric Cooper]

On Fri, Aug 31, 2007 at 06:30:19PM +0200, Mathias Kende wrote:
> Le jeudi 30 ao??t 2007 ?? 23:47 +0200, Markus E L a ??crit :
> > A check in the Unix library would be nice, in the long run I think
> > using 32bit native integers is absolutely required. 
> 
> I had the same sort of problem with the Unix.stat function and the
> st_size member being an int while it is a 64 bits int on recent systems
> (including some 32 bits one). The maximum size that can be stored on 32
> bits system, 1Go, is much too small for this function.

This one is solved by the Unix.LargeFile sub-module.

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] int overflow and Marshal failure

[Vincent Hanquez]

On Fri, Aug 31, 2007 at 06:30:19PM +0200, Mathias Kende wrote:
> Le jeudi 30 août 2007 à 23:47 +0200, Markus E L a écrit :
> > A check in the Unix library would be nice, in the long run I think
> > using 32bit native integers is absolutely required. 
> 
> I had the same sort of problem with the Unix.stat function and the
> st_size member being an int while it is a 64 bits int on recent systems
> (including some 32 bits one). The maximum size that can be stored on 32
> bits system, 1Go, is much too small for this function.

Unix.LargeFile.stat returns a proper structure with 64bits st_size.
I wish that was directly Unix.stat though ...

-- 
Vincent Hanquez

Re: [Caml-list] int overflow and Marshal failure

[Brian Hurt]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

Mathias Kende wrote:

>Le jeudi 30 août 2007 à 23:47 +0200, Markus E L a écrit :
>  
>
>>A check in the Unix library would be nice, in the long run I think
>>using 32bit native integers is absolutely required. 
>>    
>>
>
>I had the same sort of problem with the Unix.stat function and the
>st_size member being an int while it is a 64 bits int on recent systems
>(including some 32 bits one). The maximum size that can be stored on 32
>bits system, 1Go, is much too small for this function.
>  
>
As a side note, this is why I think the x86 should have gone 64-bit a 
decade ago now (and was saying that then).

Apparently, 2G should be enought for anyone.

Brian


[-- Attachment #2: Type: text/html, Size: 1105 bytes --]

Re: [Caml-list] int overflow and Marshal failure

[Matthieu Dubuget]

Mathias Kende a écrit :
> Le jeudi 30 août 2007 à 23:47 +0200, Markus E L a écrit :
>   
>> A check in the Unix library would be nice, in the long run I think
>> using 32bit native integers is absolutely required. 
>>     
>
> I had the same sort of problem with the Unix.stat function and the
> st_size member being an int while it is a 64 bits int on recent systems
> (including some 32 bits one). The maximum size that can be stored on 32
> bits system, 1Go, is much too small for this function.
>   
I think that the Largefile sub-module solves this problem.

Salutations