You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to set up a MySQL cluster such that some participants have read-only access, and others have full admin access to the database?
The read-only participants would not be able to Create Table, Insert, Update, Drop, Delete, etc. But they would still receive and propagate updates made from the write-access participants.
From what I understand, when someone has your ipfs/p2p service_discovery_id and service_command_topic, they have full admin access to the database depending on the local MySQL User rights. So all nodes in the network must be trusted not to abuse the system.
Say, instead, we make two p2p IceFire-Proxy clusters: one service_discovery_id/_topic for the Writers, and another combo for the read-only access.
And then we set up both zones to the same local MySQL database, only using different MySQL local accounts with different access: a readonly user and the normal root user.
Any suggestions on how to hook up some rudimentary access control with the SQL Proxy?
Questions:
Could the SQL Proxy pick up and publish changes made directly on the MySQL local db by another SQL Proxy instance in real time? Would we need to add triggers?
What happens if the SQL Proxy receives a database error from the local node (say, from access denied)? Will it propagate the request anyway to the next nodes?
What happens if the node receives an abusive SQL query that creates a database error from someone else? Will that be propagated to all participants too?
Thank you very much for your suggestion,the proposal on authority management is very valuable. Regarding user authority and node network authority, we are currently building the icegiant project. icegiant will use cosmos to build the blockchain layer and user system , and add control functions such as user management and node access control for the IceFireDB storage engine. But at present we have not set icegiant as a public repository, when IceGiant is open source, I will contact you again.
In the SQL proxy part, there is currently no statement security detection, mainly integrating the broadcast of the p2p mode, but your suggestion is very valuable. We will consider adding some verification mechanisms in the proxy layer of the icefiredb engine, but our focus will be on some functions of database statement detection in icegiant.
Thanks again for your project suggestion, if there is an update on the relevant solution, we will reply you here 🤝.
Would it be possible to set up a MySQL cluster such that some participants have read-only access, and others have full admin access to the database?
The read-only participants would not be able to Create Table, Insert, Update, Drop, Delete, etc. But they would still receive and propagate updates made from the write-access participants.
From what I understand, when someone has your ipfs/p2p
service_discovery_id
andservice_command_topic
, they have full admin access to the database depending on the local MySQL User rights. So all nodes in the network must be trusted not to abuse the system.Say, instead, we make two p2p IceFire-Proxy clusters: one
service_discovery_id/_topic
for the Writers, and another combo for the read-only access.And then we set up both zones to the same local MySQL database, only using different MySQL local accounts with different access: a
readonly
user and the normalroot
user.Any suggestions on how to hook up some rudimentary access control with the SQL Proxy?
Questions:
Thanks!
I now see that the Redis proxy has all commands configured as either
read
orwrite
commands here: https://github.com/search?q=repo%3AIceFireDB%2FIceFireDB%20AddReadCommand&type=codeSay we abandon SQL and want to use Redis for this instead.
Could this system be used to check that Write commands only come from allowed nodes?
The text was updated successfully, but these errors were encountered: