>First-class multi-application PAGs would not be so cheap in the kernel, >and there would have to be a finite number and registry of applications >to prevent resource consumption attacks. Adding applications to the >registry would be a complication (you don't want to have to reboot for >that) requiring privilege.
I read your stuff about multi-application PAGs, and I guess I didn't understand it. I mean, it seems like if you want to store multiple "blobs" (which is all I envision PAGs as doing), it's not THAT much more work. If you're concerned about space, just put a fixed limit on how big those blobs can get (my thinking was that there's a field in the process, or maybe the creds structure, that points to the PAG structure). >> (I am personally not worried about the API; I'm sure whatever the API ends >> up being, it will be fine. It's the implementation that concerns me). > >Do you prefer a kernel-land implementation? Well .... given my druthers, I'd prefer that the BLOBS (e.g., what is likely going to be Kerberos tickets/keys) be in the kernel. I guess I don't care if there's a userspace daemon that does management of those blobs; I'd just rather not have the blobs in userspace. But I'd even be satisfied with what you describe, as long as the inheritance model was the same as PAGs today. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
