On Thu, 2011-11-03 at 13:57 -0500, Nico Williams wrote: > On Thu, Nov 3, 2011 at 11:31 AM, Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Thu, 2011-11-03 at 11:05 -0500, Nico Williams wrote: > >> If the proxy daemon process dies, how should the proxy client recover? > > > > Either wait for the proxy to restart or treat it as an unrecoverable > > error, just like if the network goes away ? > > If state is lost the client has to recover. Sure, it's going to > somehow (perhaps by returning an error to the user, who then retries). > Point is: a stateless (or stateless + caching, for perf) design would > avoid this. > > For the protocol that just means that handles need to be opaque octet > strings, NOT just small integers. Whether a given implementation is > stateless is another story. This is what I was driving at. > > > Ok, I can see how this may help. > > :) > > >> There's no complication. The protocol needs to allow for > >> arbitrary-sized object handles -- that's all. > > > > Ok, I was complaining about making the server more complicated, but > > that's probably not really true, we will just trade one set of issues > > with another as the state is kept 'somewhere' anyway, so I retire my > > concern. > > Right. > > >> I'd much rather not have to pass anything, but we need to support OSes > >> where that's just how it's done. I'd rather that IPC end-points can > >> find out what what they need about their peers. Think > >> door_ucred(3DOOR). > > > > I don't think I want to use the PID and then try to pull out environment > > variables through /proc or similar interface, that would be bad. > > I would never have suggested that. > > What I had in mind was something like PAGs or keyrings. Or, to be > much more specific, search for my name and the string "credentials > process groups" -- a PAG on steroids. > > The idea is that the IPC peer can observe the other's > PAG/keyring/CPG/whatever and use that to find the correct credentials > (authorization is still required though). Linux already has per-user, per-process and per-thread keyrings which offer a high security storage solution for keys. The problem with those is that they are difficult to use in an asynchronous context when the original user's process/thread context is no longer available to us. Ideally, though, that's what we'd like to see used. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
