Re: [PATCH v8 0/9] NFSD support for async COPY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

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.

> I wonder if there's also the possibility of weird results even without
> malicious intent: e.g. a user copying files between two different
> servers may unintentionally tie up resources on the target server.

Is the target server in your case a target of the copy? The copy is initiated and will use resource of the copy source server and the copy destination server until either copy is done or client cancels the copy or client’s lease expires on the target copy server. 

> There's interest in enabling unprivileged NFS mounts to allow
> unprivileged containers to do NFS mounts.  But even if we get to the
> point where we're comfortable enabling that, distributions may still
> want it off by default, and may advise admins to do firewalling that
> restricts the set of NFS servers that containers can mount.
> 
> --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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux