(Illustration by Gaich Muramatsu)
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. JanReceived on 2016-05-16 14:38:36