On Tue, 24 Feb 2015, J. Bruce Fields wrote: > On Mon, Feb 23, 2015 at 05:22:12PM -0800, Benjamin Coddington wrote: > > That sounds a lot closer to some of the work I've been doing to see if I can > > come up with a way to solve the "where's the namespace I need?" problem. > > > > I agree with Greg's very early comments that the easiest way to determine > > which namespace context a process should use is to keep it as a copy of > > the task -- and the place that copy should be done is fork(). > > So you're suggesting that the key_agent could be that copy? But: > > > ... If not, then the calling process itself is forked/execve-ed into a > > new persistent key_agent that is installed on the calling process' > > keyrings just like a key, and with the same lifetime and GC > > expectations of a key. > > > > A key_agent is a user-space process... > > If the key_agent can die before it's needed, then we have to keep around > some other context information to allow regenerating a new one. So what > is that piece of information? Aren't we back where we started?
Yes. It would seem to make sense then to keep a copy of task which would be used to create the user-space key_agent. If that's the standard behavior, it doubles the number of tasks for the average use case. The average use case (I anticipate) would be to just always fork the caller if a key_agent is not found. It would probably make sense provide the key_agent_type the option of binding a key_agent reference task to another structure -- like a mount. And, if so, that reservied reference task would be used to create/re-create the user-space key_agent. The trouble there is how to have the caller communicate the object bound to the task.. a reference to the object could be guessed, which would give any caller access to a that reserved task.. In order to keep further verbose speculation to a minimum, I'll say: good point.. there may be a way to authorize the usage of a reference task by means of the possession of an authkey. I'll keep hacking at this. Ben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
