On Nov 14, 2007, at 6:33 AM, will young wrote:
Shawn M Emery wrote:
Henry B. Hotz wrote:
On Nov 8, 2007, at 8:30 AM, Douglas E. Engert wrote:
2) Ticket stores should be per-session.
Yes, but I think there should also be a way of acquiring a TGT
from outside of the session. For example; processes that are long
running or delayed execution could use credentials acquired from
another mechanism, such as from password authentication or
delegation.
I haven't looked recently but in general there have not been
cohesive sessions to tie processes (and kernel actions) to unless
auditing is enabled.
-Will
All of us seem to have interpreted this comment differently, or at
least to have very different concerns related to it.
My concern when I wrote that is that the credential cache for a
console login should be independent from the one for an ssh session
(and each ssh session should be independent from the others)
*even*if* they are for the same nominal user and UID. Maybe I want
my credentials erased when I logout, but I don't want the ssh session
killed when I log out from the console. If you're not concerned with
actual secure isolation this could be as simple as a per-session CC
name. I'd *like* something akin to an AFS PAG with actual secure
isolation as well, but I know that's hard.
Maybe network identities are independent of local UID and there's
just no correspondence at all.
One use case we have here is an operator console for e.g. a testbed.
It runs continuously, and nobody *ever* logs the console out. OTOH
the person in front of the console changes every 8 hours. I've been
advocating that the operator do a kinit/klog at shift change. Then
network operations and logs can be traced to the real person on duty,
but you don't have to kill/restart all the monitoring processes.
Making this work right goes to my first point as well, of course.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
