[SERVER-25890] Prevent user-initiated writes to the system.views collection Created: 31/Aug/16  Updated: 06/Dec/22  Resolved: 25/Jan/17

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-25942 listCollections should not validate v... Closed
is related to SERVER-30644 Deadlock involving ViewCatalog mutex Closed
Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Work was done in SERVER-25723 to avoid crashing a secondary upon replicating a structurally invalid view definition (i.e. one with unknown fields or incorrect types). We should consider whether it's possible and that we're willing to reject user-initiated writes to the system.views collection. One approach would be to return an error in the following functions that were introduced by redbeard0531's work in SERVER-23128. The parsing and validation would be performed prior the catalog operation that actually does the write and should not impact the replication of views.

It is worth mention that issues such as SERVER-25492 and SERVER-25680 were only identified as a result of a user being able to write directly to the system.views collection. Since we may end up changing the document structure of a view definition in a future release (e.g. by adding a new option), we may want to be able to retain the ability to write directly to the system.views collection for testing purposes.



 Comments   
Comment by Eric Milkie [ 25/Jan/17 ]

Fuzzer is going to proceed with SERVER-27813 instead.

Comment by Andy Schwerin [ 25/Jan/17 ]

As originally conceived, the "root" role should have done this, but somebody gave "root" "restore" privileges, which might have removed the utility of that.

However, you could create a user with the roles "readWriteAnyDatabase", "clusterAdmin", "dbAdminAnyDatabase" and "userAdminAnyDatabase" – and optionally "backup".

Comment by Max Hirschhorn [ 25/Jan/17 ]

Does the fuzzer have auth on? I'd prefer that the access control system
guard this, rather than special logic.

schwerin, are you proposing that we have the fuzzer always authenticate as a user that doesn't have permission to write to the system.views collection? Is there an easy way to express having all privileges on the cluster, databases, and collections, except for "insert" and "update" on {db: "", collection: "system.views"}?

Comment by Andy Schwerin [ 25/Jan/17 ]

Does the fuzzer have auth on? I'd prefer that the access control system
guard this, rather than special logic.

Comment by Eric Milkie [ 25/Jan/17 ]

We should reconsider doing something about this now that 3.4.0 is released. With the current behavior, the fuzzer is able to create invalid views that cause test failures, yet blacklisting this behavior in the fuzzer is something I'd like to avoid if possible.

Generated at Thu Feb 08 04:10:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.