32 Bit UIDs For Unix?

Ghidra asks: "I work for an ISP and we now have UIDs greater than 65535. I thought by upgrading to Linux 2.4 (and having fairly current utilities) that I would be able to support these UIDs. Unfortunately, it doesn't look that easy. It also doesn't look like there is much help on the Internet on how to accomplish this. Things like ls, ps, chown, and the like just don't want to recognize these high numbered UIDs. So what kind of steps do I need to take to upgrade my system (Slackware-current) to support 32 bit UIDs?" What other Unix variants can benefit from this information, as I don't think Linux is the only Unix-clone that still uses 16-bit UIDs. Are there any flavors of Unix that have already solved this problem?

BSD's already have them

[platinum]

$ uname -sr
FreeBSD 4.2-STABLE
$ grep uid_t /usr/include/sys/types.h
typedef u_int32_t uid_t; /* user id */
$

I'm not sure I understand

[tzanger]

Okay you work at an ISP... but you have over 65k users who log in and use the system??

If not, use something like vpopmail so you don't need an actual unix account for each mail user. Proftpd will let you disentangle the FTP system from the unix accounts as well.

If you actually have that many people using shell accounts you should look into recompiling a lot of yoru standard utility packages: Util-linux, net-tools (I think), etc. Simply recompiling will probably solve your problems since they will be linked in with 32-bit UID support (I don't know of any distros which use 2.4.x as standard yet).

2.4 gets you halfway there

[weefle]

There are two major things that must be upgraded in order to get 32-bit UID's, and you've got one of them already. The other is the C library. The Linux 2.4 kernel has support for 32-bit UID's, but all the executables on your system are linked against a C library which must also know about big UID's.

32-bit UID's are supported in version 2.2 of the GNU C library. Red Hat Linux 7 will provide you with glibc 2.1.92, which, after upgrading to a 2.4 kernel, does the trick just fine. I tried out 32-bit UID support with the first publically available RH7 beta, and it worked like a charm.

You need kernel 2.4 *and* glibc 2.2

[Chronoforge]

I thought the same thing you did, and tried 32 bit UIDs on a RH6.2 box with the 2.4-test kernels. It failed, and there was much weeping and gnashing of teeth.

When RH7 came out, I put that on my desktop and installed a 2.4-test kernel, and it's been running beautifully ever since. And there was much rejoicing.

Dave, with a UID of 2015001 and NFS mounting from a big AIX box

Re:I'm not sure I understand

[eufaula]

qmail has native tools (users/assign) for having virtual usernames with one system account. I have a machine with over 10,000 users on it and only one system account. makes for much better security.

Re:What about web pages?

[sql*kitten]

Put the userid, the password and the home directory into the database. Authenticate off the database (might need to customize your FTP server to do this), and chroot() to the home directory. So long as you have the web server set up to chroot() when executing CGIs (and have the approriate hardlinks on your filesystem for binaries/libraries) you can have all the web sites owned by the same Unix user. I did this for an ISP back in '97 or so, with a few thousand users.

Re:I'm not sure I understand

[tzanger]

qmail has native tools (users/assign) for having virtual usernames with one system account.

True... I prefer qmailadmin and vpopmail, both by inter7.com. They use the standard qmail configuration files and provide a very nice interface. Throw in Courier-IMAP and Squirrelmail and you have one kick ass mail server. Fast, configurable and reliable, and all with about 7 user accounts used (qmail uses about 4 or 5 and vpopmail uses 1 or 2) irregardless of how many virtual domains or mail users you have.

What about web pages?

[coyote-san]

UIDs aren't just required for shell access and mail. Most ISPs provide web space now, and some mechanism to allow the user - and that user alone - to modify the content. Maybe HTTP PUT, maybe FTP. The standard file systems ownership fields are one way to handle this if you're using the standard servers.

Re:What about web pages?

[tzanger]

UIDs aren't just required for shell access and mail. Most ISPs provide web space now, and some mechanism to allow the user - and that user alone - to modify the content.

I addressed this in my original post: Proftpd and its own passwd file. Set all the user accounts to some arbitrary UID/GID (I created a web user which apache runs as) and the user's directory set to /www/users/[username]. Proftpd is then configured with "Userdir ~" or some such thing (It's late here) and when the user logs in they are scooted off to their own directory and can't get below that. Not exactly a chroot but then again this isn't shell we're talking about.

Yeah if they compromised proftpd they could get access to and fuck with my apache install but then again, that is why I'm running proftpd and not wu-ftpd.