Add description about permission restrictions

docs/design/2021-04-26-lock-view.md

@@ -1,7 +1,7 @@
 # TiDB Design Documents
 
 - Author(s): [longfangsong](https://github.com/longfangsong), [MyonKeminta](http://github.com/MyonKeminta)
-- Last updated: April 29, 2021
+- Last updated: May 6, 2021
 - Discussion PR: N/A
 - Tracking Issue: https://github.com/pingcap/tidb/issues/24199
 
@@ -57,6 +57,8 @@ Several tables will be provided in `information_schema`. Some tables has both lo
 * Collecting, storing and querying:
     * All these information can be collected on TiDB side. Since the amount of concurrent transactions won't be too large, and it doesn't need to be persisted, so it's ok to implement it as a memory table. For querying among the cluster, just register the table under `infoschema/cluster.go` and write the global table name with the local one.
     * As the simplest way of implementing, most information can be passed with a similar way like `ProcessInfo`, or even directly passed via the `ProcessInfo` struct.
+* Permission:
+    * `PROCESS` privilege is needed to access the full content of this table. For users without `PROCESS` permission, only transactions started by the current user will be shown, and others will be filtered out, which is similar to the `processlist` table.
 
 ### Table `DATA_LOCK_WAITS`
 
@@ -74,6 +76,8 @@ Several tables will be provided in `information_schema`. Some tables has both lo
 * Collecting, storing and querying:
     * All these will be collected on TiKV LockManager, and will need a new RPC entry for TiDB to query. LockManager won't store the un-hashed key or SQL_DIGEST for now, so we need to modify it.
 * The SQL Digest of the transaction that's currently holding the lock may be helpful, but it's hard to implement under the current architecture. So it won't be included in the first version of the feature.
+* Permission:
+    * `PROCESS` privilege is needed to access this table.
 
 ### Table `(CLUSTER_)DEAD_LOCK`
 
@@ -93,7 +97,8 @@ Several tables will be provided in `information_schema`. Some tables has both lo
 * Collecting, storing and querying:
     * All of these information can be collected on TiDB side. It just need to add the information to the table when receives deadlock error from TiKV. The information of other transactions involved in the deadlock circle needed to be fetched from elsewhere (the `TIDB_TRX` table) when handling the deadlock error.
     * Currently there are no much information in the deadlock error (it doesn't has the SQLs and keys' information),  which needs to be improved.
-
+* Permission:
+  * `PROCESS` privilege is needed to access this table.
 
 ### Protocol