On Tuesday, May 11, 2004 14:34:44 -0400 Matthew Miller <[EMAIL PROTECTED]> wrote:
On Tue, May 11, 2004 at 02:01:37PM -0400, Jeffrey Hutzelman wrote:It had better not be. As administrator of a machine, the GID space is entirely under your control. If you're going to run an AFS client, you
Think larger than "a machine".
I do, every day. But really, just because you manage lots of machines doesn't mean you have to make every decision and perform every task separately for each one.
And the statement stands. Either you have control over a machine, or you don't. If you do, then when you decide that machine is going to run AFS, you're going to also have to commit to setting aside some GID space. Making that decision for every machine simultaneously makes the task _easier_, not harder, if you've done things right.
In the entire time the Carnegie Mellon University School of Computer Science Research Computing Facility (what a mouthful) has been in existence, the highest UNIX GID we allocated seems to be about 524. We stopped allocating groups entirely several years ago, since with most data in AFS there really isn't much need. The highest PTS group ID allocated is -3916; recall that pts groups can be created by users at any time.
currently need to reserve GID's in the range 0x3F00-0xFEFF for AFS. That still leaves 16K groups for non-AFS uses, which is far more than most systems will ever need.
And what, exactly, is one supposed to do with forty thousand IDs already allocated in the range that suddenly AFS declares for its own? You can't just do that. It's fundamentally broken.
There's nothing "suddenly" about it. It's worked this way for a very long time. And yes, we can do that; we've been doing it this way for a very long time. As I said previously, it works pretty much everywhere.
As for "fundamentally broken". Well, I'll agree that it's distasteful. But it's less distasteful than making intrusive, difficult-to-maintain changes to something like 15-20 operating systems(*) to provide a reasonable model for tracking credentials.
From what you've said, it sounds like the group space you're using doesn'tactually conflict with what AFS uses for PAGs. Don't allocate groups in that range, and you'll be fine.
If you'd rather it be some other range, I'm sure the gatekeepers would be happy to accept a patch which allows the range of groups used by PAGs to be changed at compile time, or preferably at startup time.
If you'd rather not use PAGs at all, I'm sure the gatekeepers would be happy to accept a patch that allows the feature to be disabled.
If you'd rather have a PAG mechanism that doesn't depend on storing data in the supplementary groups list, join the club. Convince your OS vendor(s) to adopt a mechanism that provides what we need.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
(*) 15 is a conservative count. At various times, AFS has run on
multiple versions (sometimes significantly different) of all of
the following:
AIX, AOS, A/UX, Darwin/MacOS X, FreeBSD, HP-UX, Irix, Linux, Mach,
NetBSD, OpenBSD, OSF1/DUX/Tru64, SunOS/Solaris, Ultrix, Windows_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
