On Wed, May 04, 2016 at 09:01:00PM -0400, Jan Harkes wrote:
> pioctls would have to get implemented as some
> sort of virtual filesystem (similar to /proc /sys) probably somewhere
> under the same /coda root, we already use a hidden /coda/.CONTROL for
> global pioctls, so maybe something like that could become a root
> directory for a pioctl-fs where writing/reading virtual files would
> replace the current set of ioctl operations and still maintain the
> proper kernel-level tagging of user identity, which is more important
> than ever with namespaces you cannot just connect over a tcp or unix
> domain socket and prove you are in the same filesystem namespace as your
> /coda mountpoint.

Would you give an example of when/how a uid check would break if
venus would listen for connections from user processes
say on "/run/.coda_pioctl_socket"?

I understand that Linux namespaces make the matter complicated,
but not why the uid check becomes unreliable. A clarification would help.

An alternative solution might be using RPC2, locally.

A separate and trivial daemon could react on locally authenticated (if
the platform allows this) or even anonymous local connections claiming to
represent a certain uid (possibly in a somewhat limited range, to avoid
a DOS?), by placing a uid-specific secret in a local file readable only
for the uid and for venus, if there isn't one, like /tmp/coda_auth/<uid>
/tmp/coda_auth being drwx--x--x .
This could be otherwise even incorporated into venus.

Then the user process like clog or cfs would have to trigger the secret
creation and then use the secret for pioctls. Given that there is hardly
much sense in unauthenticated Coda operations, it would be sufficient
to let clog trigger the secret creation.

This would be portable and fully user-space. Performance is hardly
crucial in this case and we would use the nice RPC2 framework which we
have at hand (pioctls are RPCs, aren't they?).

On Fri, May 06, 2016 at 08:28:27AM +0200, I wrote:
> AFAICT on Linux, FreeBSD and NetBSD we could instead talk over a local
> socket and reliably inquire the identity of the other party

There is a pending project of reinstating the FreeBSD Coda kernel module.

If we make a change in venus/cfs/clog/repair to replace pioctl with
a user-space solution then the kernel module would be simplified.

Jan, do you believe such a change would be feasible?

Would this be easier or harder compared to using reads/writes over a
virtual filesystem under /coda?

Would you point out which places in the code have to be touched/checked
in case we would decide to make the one or the other change?

Regards,
Rune