[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon? Workarounds?

[Jeffrey Hutzelman]

On Tuesday, May 11, 2004 14:34:44 -0400 Matthew Miller <mattdm@mattdm.org> 
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't 
actually 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) <jhutz+@cmu.edu>
   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