On Fri, Sep 30, 2016 at 03:54:58PM +0200, u-x417_at_aetey.se wrote:
> Returning to how to improve/replace pioctl().
> 
> Why not combine the two proposed approaches:
> 
> On Mon, May 16, 2016 at 02:38:22PM -0400, Jan Harkes wrote:
> > I think the virtual file system would be the cleaner and better solution
> > because we already have to present a file system interface to the user
> > anyway, considering that is the main purpose of a file system.
> 
> On Tue, May 17, 2016 at 10:53:56AM +0200, u-myfx_at_aetey.se wrote:
> > > > An alternative solution might be using RPC2, locally.
> 
> We might let venus keep a table of secrets "per active uid" and offer
> these in virtual files like /coda/.pioctlsecret/<numeric_uid> where
...
> Then clog/cfs/repair would be able to use rpc2 to talk to venus, all code
> needed to handle data passing is already present in rpc2.
...
> I appreciate if Jan (or anyone) would comment on this idea.

If we already have to go through the trouble of creating a virtual file
system, then I don't see the benefit of using rpc2.

Also the numeric_uid numbers are not necessarily consistent between
application, kernel, and venus processes so that probably wouldn't be a
good thing anyway. The reason for this is the continued push for
restricted namespaces and other forms of containerization.

A long term benefit that I can see it that this replaces/surpasses the
functionality of the PAG (process authentication group) in AFS. It
allows the system to distinguish a user who logs into a machine over SSH
from the same user logged in locally and can be used to prevent them
from sharing the same Coda credentials.

Since most ioctls are pretty simple in their purpose I think 90% or more
should be about as hard as, or possibly easier than, getting the
pioctlsecret file to work (getvolinfo, listcache, listlocal, getfid,...).

Jan