Hello Jan,

Thanks for the reply.

On Mon, May 16, 2016 at 02:38:22PM -0400, Jan Harkes wrote:
> > > 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"?

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

I did not test namespacing but looking at the documentation it seemes
like user-created namespaces would translate to the corresponding user uids.
Otherwise in the worst case this could be worked around by running a venus
per namespace. But actually I like the thought of using RPC2 even better.

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

That's the point. It is a venus companion (or venus itself) which can
create the shared secrets per user and [assuming sufficient privileges]
make the secrets accessible only to the concerned user.

> 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 clog, but venus (or a dedicated "venus companion").
Clog or some other triggering tool has only to initiate the creation.

> 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

It is to be a separate secret, shared between venus and the user
and only being used for local RPCs.

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

Sorry, you lost me. I strongly believe I can create a local file readable
by a single uid and by a dedicated group which has a single member
(which venus would use).

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

Now I follow you. This is the situation where a companion root daemon
would be well suited for creating the secrets on demand. It does not even
have to interact with venus at all.

> Also, namespaces, the user and venus might not
> actually see the same /tmp directory. This is an assumption some current

That's a different matter and applies to seeing the same /coda directory
as well.

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

When nothing else helps, let the concerned party run a separate venus,
why not?

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

This isolation approach is one of many, like chroot or virtual machines
or younameit. All of them introduce various inconvenient constraints
on purpose.

It is not necessarily our task to work around those.

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

This sounds reasonable. OTOH the file system interface is not sufficient
per se, an RPC layer on top of it has to be created from scratch.

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

Thanks.

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

You are right, sharing the data representation is simple and efficient.

Despite the efficiency, the assumption that venus and the user-side
programs like cfs and in a slightly different sense also the kernel
module must share a binary representation of data always seemed somewhat
inconvenient to me.

We'll see how hard it is to make a change.

Best regards Jan,
Rune