On Mon, Apr 03, 2006 at 04:43:07PM -0400, Jeffrey Hutzelman wrote: > On Monday, April 03, 2006 02:01:21 PM -0500 Nicolas Williams > <[EMAIL PROTECTED]> wrote: > >On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote: > > > >Since you've agreed that PAGs are not a session separation feature I'll > >just put you firmly in that column and ignore any further protestations > >that PAGs are a form of "weak separation" ;) :] > > Fine. It's really just about making identity selection work in a sane way. > The idea is that if I start a new PAG, and get reduced or no credentials in > that PAG, then ordinary file accesses actually fail when they're supposed > to, rather than randomly succeeded.
Yay! :-) > >Oh no, not "for every vnode or file op" -- for every authentication > >attempt. Surely AFS does not do an AP exchange "for every vnode or file > >op," right? Right?! > > > >Please tell me that it doesn't... If not I may have to laugh at AFS :) > > No, of course not. Actually, that's part of my point. We avoid doing that > by caching established connections and indexing them by PAG, and we avoid > _using_ even the cached connection on every op by also caching metadata, > file contents, and access rights. But if mapping the in-kernel PAG to the > identifier AFS actually uses requires an upcall, then I have to do the > upcall on every vnode and file op, because that's pretty much how often I > have to examine cached access rights (actually, it's not quite _that_ bad, > but it's close). Ah, OK, I get it. *This* is a kernel-side application of PAGs, yes. But: - it doesn't necessarily have to be distinguished as an "application" as the other examples of multi-app PAG consumers do (see below) - you only need to upcall when a PAG->connection cache lookup misses The only question I have then is: how to deal with new PAGs that are intended to share their predecessors' AFS connections/credentials? And I think the answer would either be: add an AFS-specific syscall to establish the new_PAG->old_connection association or bite the bullet and re-authenticate using the PAG->credentials association kept in user-land. I expect this sort of event to be rare. How often do users setpag(2)? > I'm beginning to think that maybe there is some unstated assumption here, > and we are talking past each other. In your user-mode multi-app PAG world, > what would you have me do to find the cached access rights that apply to a > process? Maybe your answer to this will uncover the disconnect. Yes, you've identified the disconnect. But I think there's an answer (see above). > >>Yes, you could do that. Those wouldn't be the same semantics as AFS, > >>but that's not necessarily a problem. It _would_ be very similar to > >>the semantics of Kerberos file ccaches, which can also be useful. > > > >Since you agree that PAGs are not a session separation feature I don't > >see how the semantics of this "join PAGs I own" feature would be > >incompatible with the semantics of AFS PAGs, but an extension. > > It's complicated, in part because different people have different > expectations. Step out of the world of perfect security for a moment, and > consider the real world. In the real world, there are people who assume > that because we explicitly don't provide an interface for PAG-joining, you > can't do it. Some of those people are blissfully unaware that there are > ways to do it anyway. Others know full well what they're getting into, and > consider it a problem to eventually work around. Sorry, but I think those users will be as blissfully unaware of the one thing (that PAGs aren't for strict separation) as of the other (that 'lo, you can "join" existing PAGs). > Personally, I happen to think that being able to join your own existing > PAG's would be fine. But I _know_ there are AFS-using sites out there that > feel differently. Too bad. They're trusting PAGs more than they should. If they really need a session separation feature then they need trusted OS labelling. > >I should correct myself here -- the right way to implement "join PAGs > >one owns" in the scheme I've proposed is to find the associations of the > >PAG you want to join, join new PAG instead, and then establish all those > >associations for the new PAG. (To keep continuity I'd make associations > >to PID before joining a new PAG -- "make before break.") > > Hm, so you don't get to arbitrarily change your PAG, but you do get to set > existing associations. That's interesting, because it could potentially > allow each application to decide whether its ID's can be joined. That > might well satisfy the people who want to use PAG's for process separation. Exactly! :) Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
