Hope? :) To get the actual value, one should probably explore uid_t type definition if you want to skip reading sources of the shadow suite. Online search returns this nice and clickable page: http://lxr.free-electrons.com/ident?i=uid_t
This leads to "unsigned int" as final definition. On 64-bit systems someone, who is not versed in C, might expect that this is an 8-byte value, but in fact it is a 4-byte value. You can test the "unsigned int" size by following instructions on this page: http://stackoverflow.com/questions/10197242/what-should-be-the-sizeofint-on-a-64-bit-machine (On my 64 bit system this returns 4 bytes.) I agree with the manoeuvrability assessment though :) b. On 28 February 2015 at 13:17, Xavier Gendre <[email protected]> wrote: > Hi, > > a priori, no problem with doing that. Simply deal with /etc/subuid and > /etc/subgid (on debian-like system, at least). For the limit, I don't know > but the man page for newuidmap considers "integers". Thus, we could hope to > deal with 2^32=4294967296 ids. In such a case, you have some room to > manoeuvre ;-) > > Xavier > > Le 28/02/2015 12:24, [email protected] a écrit : > >> Hi, >> >> I am looking into individual user namespaces for each container. >> The first container could have uids and gids from 100000 to 165536. >> The second container could have 200000 to 265536, couldn't it? >> How far can I go? Is there a limit? >> >> Thanks, >> David >> >> >> _______________________________________________ >> lxc-users mailing list >> [email protected] >> http://lists.linuxcontainers.org/listinfo/lxc-users >> >> _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
