[1002] in arla-drinkers
Re: PAM and arla
daemon@ATHENA.MIT.EDU (Derrick J Brashear)
Wed Jul 21 15:39:07 1999
From owner-arla-drinkers@stacken.kth.se Wed Jul 21 19:39:06 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 10987 invoked from network); 21 Jul 1999 19:39:05 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 21 Jul 1999 19:39:05 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id VAA16781
for arla-drinkers-list; Wed, 21 Jul 1999 21:34:26 +0200 (MET DST)
Received: from alycia.dementia.org (ALYCIA.DEMENTIA.ORG [128.2.35.149])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id VAA16777
for <arla-drinkers@stacken.kth.se>; Wed, 21 Jul 1999 21:34:20 +0200 (MET DST)
Received: from johnstown.andrew.cmu.edu (JOHNSTOWN.ANDREW.CMU.EDU [128.2.121.156])
by alycia.dementia.org (8.9.1a/8.9.0) with SMTP id PAA01086
for <arla-drinkers@stacken.kth.se>; Wed, 21 Jul 1999 15:34:46 -0400 (EDT)
Date: Wed, 21 Jul 1999 15:34:15 -0400 (EDT)
From: Derrick J Brashear <shadow@dementia.org>
Reply-To: Derrick J Brashear <shadow@dementia.org>
Subject: Re: PAM and arla
To: arla-drinkers@stacken.kth.se
In-Reply-To: <Pine.HPX.4.02.9907211515390.16146-100000@agogo.engin.umich.edu>
Message-ID: <ML-1.3.2.932585655.3894.shadow@johnstown.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
> At present, if the 2 magic groups are present, Arla uses them alone to
> figure out which PAG the current process is in; otherwise it uses the UID.
> I would suggest changing the logic so that the UID is used along with the
> PAG number derived from the magic groups to find out the current PAG; i.e.
> uid=4000, groups=33536 33521 is a different PAG than uid=0, groups=33536
> 33521.
Again, you're making it hard for people who are using this behavior (which,
intended or not, AFS has) to change PAGs, and I really wish you wouldn't. Now
that Linux has an in-kernel nfsd it won't matter, but I had also intended to
use this to allow a user-level nfsd to do the equivalent of Transarc knfs:
basically allow remote clients to have a PAG.
