[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Kerberos support for screen

From: Fredrik Tolf
Subject: Re: [PATCH] Kerberos support for screen
Date: Sat, 26 Feb 2005 21:31:29 +0100

On Sat, 2005-02-26 at 11:16 -0600, inode0 wrote:
> On Sat, 26 Feb 2005 17:30:26 +0100, Fredrik Tolf <address@hidden> wrote:
> > Hi all!
> > 
> > I was having some trouble with Kerberos and screen, so I wrote this
> > patch. Not sure if I should send patches to "screen-users", but I
> > couldn't find any other mailing list. =)
> I've been dealing with these issues for a long time too but I didn't
> perceive it to be a problem with screen.

Well, neither did I. I just perceived that screen would be a good place
to fix it. It's also a question of semantics to me. In my opinion,
you're supposed to have one ccache per session, and since screen in
essence creates a new session, I think the correct semantic is to have
screen manage a ccache for that session.

> > Anyway, my basic problems were two:
> > 1. If one logs in with Kerberos support and thereby gets tickets and
> > then starts a screen, that screen session will use the same credential
> > cache. If one then detaches the screen and logs out, the login program
> > will remove the credential cache, and the processes running in the
> > detached screen will be ticket-less. Therefore, this patch makes a copy
> > of the credential cache and ensures that all processes in the screen
> > session will use it.
> I put my credential cache in a location where it won't be deleted
> either by configuring kerberos to do that by default or by setting the
> appropriate environment variables. That seems to solve this problem
> for me.

Yeah, but then you actually have to put your ccache in a different
location, manually. That's what I wanted to avoid. :)
IMHO, everything that can be automated should be, so that's what I did.

> > 2.  If I start a screen, detach it and let it lie for some time, the
> > tickets will expire if I don't manually log in once in a while and renew
> > them manually. Therefore, this patch renews the tickets when necessary
> > (it registers an event that runs once per minute and examines if it's
> > time to renew the tickets, and does so if it deems it good).
> This one is more philosophical to me. The situations where I'm using
> screen/kerberos together tend to be on fairly secure machines where
> I'm comfortable leaving long tickets sitting on the machine. Renewing
> them is a bit annoying, but doing that once a month hasn't been that
> annoying to me. Maybe I just haven't quite made the mental adjustment
> going from krb4 philosophy to krb5 yet?

Again, I think that everything that can be automated should be, so I
decided to automate it and make screen renew the tickets. Also, I'm not
very comfortable with long-lived tickets. Maybe it's just me, but I feel
much better having tickets that can be renewed for a long time, but that
expire sooner. My tickets expire after 10 hrs, but are renewable for 10

Either way, I don't intend to shove the patch down your throat. ;-)
I just found it useful, and posted it 1) in the hope that someone else
finds it useful, and 2) it the hope that it might make it into the next
release of screen, so that I don't have to patch my machines manually

Fredrik Tolf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]