On Wed, May 11, 2016 at 04:30:35PM +0200, u-myfx_at_aetey.se wrote:
> 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"?

Well for one it would exclude Windows from ever getting a fully
supported Coda client because SO_PEERCRED only works with unix domain
sockets. FreeBSD and OpenBSD systems use getpeereid instead of
SO_PEERCRED, NetBSD has LOCAL_CREDS and Solaris doesn't have anything
similar AFAIK. And then each method has it's own little peculiarities.

On top of that, when namespaces are involved if venus is even able to
create a UNIX domain socket that is accessible outside of the
'container', the UIDs inside and outside of the container translated
differently. I haven't looked deeply at this, but it may very well be
that the uid of every user outside of Venus's container will get mapped
to a nobody user inside of Venus's container, which would defeat the use
of trying to get the uid of the other side of the UNIX domain connection.

> 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

So now we're working on trust, because there is no shared secret between
Venus and the user, so anyone can claim to be some particular user. The
only thing that can possibly authenticate the user is the Coda token,
and so every RPCioctl would have to include that so that venus can
associate the operation with a particular 'identity'. So clog would have
to scribble the token in a 'safe' place so that all the other pioctl
using commands can grab it and present it as part of their handshake.

Not that it makes the connection to Venus any better, because only
servers are capable of extracting the secret from the Coda token and we
have to give Venus the secret data in the clear. It is non-trivial and
the slightest mistake can expose a truck sized hole in the Coda client
for potential abuse.

> 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 .

You cannot assume the user can create a secret readable by only him and
venus because that would imply group membership that allows other users
in the same group to access the same secret. Venus can currently do it
because it runs as root, which is a priviledge I would love to drop as
soon as /coda is mounted. Also, namespaces, the user and venus might not
actually see the same /tmp directory. This is an assumption some current
pioctl operations are making (cfs listcache/listlocal) when there is a
large amount of data that needs to be returned to the user, but that
assumption may not be valid for too much longer.

    https://fedoraproject.org/wiki/Features/ServicesPrivateTmp

> 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?

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.

> 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?

All of coda-src/kerndep/*, coda-src/venus/vproc_pioctl.cc and probably
some of coda-src/venus/worker.cc. About 3000 lines of code, a problem
with the RPC solution (and most other solutions) is that currently
pioctls just memcpy a binary struct around but to properly handle 32/64
bit and other format issues that code is going to have to become a lot
larger to correctly handle all the individual struct fields.

Jan