[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pop3 and sendmail? (long) (shortened)

On Sun, 11 Apr 1999, Matthew Hixson wrote:

> On Sun, 11 Apr 1999, David J N Begley wrote:
> > With the NSS/PAM combination, your users will still need unique UIDs and
> > GIDs it's just that they don't need to exist in your /etc/* files (ie.,
> > an account properly added to the NDS with all the necessary attributes
> > will automatically "exist" on your Unix mail server).
> I am going to be providing email services to more than 65k users.  So can
> this solution use 32bit UID's?

Short answer - yes.

Longer answer - UIDs/GIDs are returned through an NSS module so as long as the
APIs can handle 32-bit UIDs (getpwent, &c.) then I don't see why there should
be any problem.

Investigating further, UIDs are referenced in most modern Unix C libraries
using the type "uid_t".  Looking at two systems I have at hand:

  Red Hat Linux (Intel x86) 5.2 (glibc-2.0.7-29)
  typedef __uid_t uid_t;         /* /usr/include/sys/types.h */
  typedef __u_int __uid_t;       /* /usr/include/gnu/types.h */
  typedef unsigned int __u_int;  /* /usr/include/gnu/types.h */

  Solaris 7 (32-bit SPARC)
  #define MAXUID          2147483647  /* /usr/include/sys/param.h */
  /* uid_t defined as either 'int' or 'long' depending on compiler macros */

Given that an "unsigned int" on a 32-bit machine is a 32-bit quantity, I'd say
the Red Hat Linux machine should (theoretically) be able to handle about 4
billion or so accounts, whereas the Solaris machine's limit is half that (only
because it's UID type appears to be signed - it's still got enough bits).

Anyone trying to fit a few billion accounts on the one machine though probably
has other "issues" that are far more pressing...  ;-)

Looking specifically at the RFC 2307 "uidNumber" attribute I mentioned in
relation to Luke Howard's NSS/PAM modules for LDAP, the syntax definition is
merely given as "INTEGER" (s3, RFC 2307) which does not appear to have any
limits (s6.16, RFC 2252);  presumably, therefore, there would be no problem
with this attribute either.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []