True. Shared logins are tricky, and ticket forwarding changes a lot of things. One could argue that a daemon that receives forwarded tickets should give you a new PAG. Should this be up to the daemon or be an OS decision?
The question is in which cases a default PAG is desirable or undesirable,
or where the possibility to join a PAG in some way could be a solution.
What is natural for a user? Desired semantics on multiple rsh calls to my
number crunching nodes? RSA authenticated SSH? Attaching to screen
sessions? RDP/vnc/... sessions?
The way I handle these is by leaving it up to a PAM module and daemon. These kind of decisions should be configurable from user-space, and the best place to make those decisions is there.
Yes, we are getting farther away from the original PAGs. I don't care so
much about what the current implementation does if it isn't what we really
want. Besides, similar things are likely to be included in several OSes, so
we'd better get this one right. From what I hear, OpenBSD will probably
include a sane PAG (or whatever) implementation if they get a patch. We
need a spec.
That's the goal of what I'm trying to do here, a sane set of syscalls and a
relatively simple internal structure. That way hopefully other OSes will
like the API and implement it themselves.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
