Subject: Re: BSD auth for AFS
To: Jason Thorpe <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 09/13/2003 01:58:39
[ On Friday, September 12, 2003 at 18:47:38 (-0700), Jason Thorpe wrote: ]
> Subject: Re: BSD auth for NetBSD
> You claim it is "only a slight modification", but you have provided no
> technical specifics on how it would be implemented. Do you really know
> how difficult it is (or isn't)?
I believe I do know the level of difficulty, and even if I understand it
only minimally then indeed it isn't very difficult at all.
The overall the process is still identical to the way AFS authorization
works today. All we're doing is telling the kernel to create the
initial Process Authentication Group (PAG) for a different process than
the caller. I.e. we're either modifying setpag(2) to take a PID
parameter, or we're creating a variant called something like
setpag_parent(2). We're not creating a PAG and then assigning it to
some other process so there's no chance for abuse by the superuser.
If I'm not mistaken OpenAFS may already have all the necessary features
since its klog(1) program already has a "-setpag" option which can be
used on systems which don't have an AFS-ified login(1) and which creates
a new PAG for its parent process (replacing any existing PAG). The
The difference between the two commands is that the klog command
replaces the PAG associated with the current command shell and
tokens. The pagsh command initializes a new command shell before
creating a new PAG.
The only other useful trick might be to automatically also assign the
new PAG to any direct child processes of the new owner process which
don't already have their own uniqe PAG already assigned. This would
allow the BSD Auth authenticator program to then also authenticate the
user to his default cell, assuming the user's password for that cell is
the same as his login password. I.e. the authenticator could call "klog
-password secret" on behalf of the user. Since this trick would give
the authenticator program the same PAG as the caller then the token
obtained from a successful authentication would be associated with the
user's new PAG thus saving one more step for the user and also making it
automatic for even an AFS-naive server such as the native "ftpd" to be
potentially automatically logged into the default home AFS cell for the
system (this assumes the user's system password and default home cell
password are the same, but I bet they are in many cases anyway! ;-).
Including the change to also move the credentials pointers from the
groups list to a separate field in struct ucred is obviously more work,
but I expect it would be mostly "mechanical" work, and I think it would
make the internal interface to AFS ever so much more clear and easy to
understand and follow, at least for anyone starting at struct proc. If
I'm not mistaken the main body of AFS already uses a generic function to
request the credentials of a process so the porting effort to reflect
such a change in the kernel interface is localized to one place.
Regardless this part of it is orthogonal to the modification necessary
to create a new PAG for one's parent process.
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>