On Tue, Apr 17, 2018 at 11:17:03AM -0400, Olga Kornievskaia wrote: > > > > On Apr 17, 2018, at 11:00 AM, J. Bruce Fields <bfields@xxxxxxxxxx> > > wrote: > > > > On Mon, Apr 16, 2018 at 11:52:03PM -0700, Christoph Hellwig wrote: > >> Also even if we have a good reason to add it I absolutely want a > >> config option for the feature - it is a lot code adding potential > >> attack vectors, so we should not just enabled it by default. > > > > By the way, am I forgetting some mitigation or can a client provide > > any address it wants as the source server to copy from? > > > > That opens up the server to a lot of the same risks you'd see from > > unprivileged NFS mounts--a malicious client could copy from a server > > under it's control that's modified to exploit bugs in the server's > > NFS client code. > > There is nothing in the specification that can protects from a > malicious user to initiate a copy. There is GSSv3 that were added to > prevent unprivileged server from accessing information from the source > server without the user’s knowledge. I don’t see how copy offload is > the same as unprivileged NFS mount. What copy offload feature offers > is ability to READ a very specific file. I can't remember how much more protocol you need besides READ.... If you support 4.1+ as the copy protocol then you probably also need to do EXCHANGE_ID and CREATE_SESSION? Fair enough, I agree that you're not exposing as much of the client code as an unprivileged mount would, but it's still a lot of opportunities for something to go wrong. > We do have in the pipe line GSSv3 implementation as well as the COPY > piece that uses it. It was implemented by Andy and inherited by Anna. > However, before we could submit that we need the copy offload to go > in. A malicious client can give the server credentials that a server under its control will accept. GSSv3 lets the source server authenticate the read requests, but I don't think it helps here. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
