> On Mon, Aug 14, 2000 at 05:23:40PM -0400, Bill Sommerfeld wrote:
> > > There is a desire to allow credentials to be forwarded after the
> > > connection is established. In this situation you really have no
> > > choice but to tamper with the credentials cache as root.
> >
> > I can think of a number of ways of doing this which avoid the need to
> > tamper with the credentials cache as root. (get telnetd to setuid to
> > the authenticated user; do all the cred cache maintainance in a forked
> > copy of login; ...)
> >
> > - Bill
>
> The credentials could be passed to PAM_KRB5 through the exec() barrier
> in any number of ways. They could be passed in the environment (encoded
> in, say, base64); they could passed in an open file descriptor of a
> zero-link file; something like Windows 2000's LSA service could be
> implemented, perhaps with the help the kernel. Etc...
>
> If it's possible to pass the credentials in the environment, then that's
> probably the easiest way to do it, provided that there's a way to remove
> them from the environment after PAM_KRB5 creates the credentials cache
> file (it should be possible, even without /bin/login's help).
>
> As an aside: /bin/login usually removes or defaults certain variables in
> the environment, but usually it does so using a static internal list; it
> would be nice if there way a way for the administrator to specify
> additional variables to be removed from the environment prior to
> execing the user's shell.
>
> Nico
> --
>
I'm not sure you understand what I am referring to. The user logs in
with telnetd and 10 hours later the user's credentials expire. The
user does not want to log in again to the remote host. The user gets
new credentials locally (and in the case of Win2000 the operating
system does this for you automatically) and wants the new credentials
forwarded to the host. There is no /bin/login or /bin/su process
being executed by telnetd. That already happened when the initial
credentials are received.
What is required is for the telnetd process to update the user's
credentials cache after the user is already logged in.
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * kermit-support@kermit-project.org
