Subject: Re: RFC: migration to a fully dynamically linked system
To: None <email@example.com>
From: Simon J. Gerraty <firstname.lastname@example.org>
Date: 12/21/2001 15:27:06
Greg Woods writes:
>[ On Friday, December 21, 2001 at 16:20:48 (+0100), Matthias Buelow wrote: ]
>> I'd greatly appreciate a flexible PAM(-like) scenario, tho.. the
>> way authentication is ATM is a bit unsatisfactory, IMHO. Some kind
>What exactly do you think you need to dynamically, at run-time in a live
>system, change about the way your system does authentication?
When you use PAM to authentictate to say a radius or tacplus server, there
can be the notion of a local template user id that exists in the local
password file. The radius or tacplus server can authenticate "user"
and also pass back an attribute to the caller to indicate the real pwd
entry to be used. Granted this ivolves a little insest, but the net effect
is very desirable among our customers (I don't mean netbsd).
>Would you not be happy with making a decision about authentication at
>install time and sticking to it for the working lifetime of the system?
In a word "NO". Please keep in mind that not everyone builds systems
purely for their own use. PAM allows the same binaries to be shipped to
different users, who can chose which authentication methods to support
and in what order.
Of course PAM is not unique in that regard, BSD-auth would do too, though
I'm not sure how you'd deal with the template user aspect in that case.
Now I admit, that a fully dynamic system would give me pause.
But I've been known to keep the crunchgen'd cat (and as many links as you like) about from the installation media and found it handy on more than one
occassion. Perhaps standardizing on a location for a crunchgen'd recovery
set would go a long way to reducing the percieved risks of all dynamic
setup at minimal overhead.