-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: redact SqlOption in SHOW CREATE #14310
Conversation
As an alternative solution, instead of implementing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this approach can't handle all cases (e.g., we can still use Display/Debug
without redaction)i.e., we need to call it explicitly, but it's acceptable to me. @BugenZhao How do you think?
Regarding this implementation, what about adding a visitor, and impl redaction as a visitor?
Oh, upstream apache/datafusion-sqlparser-rs#765 (But it might have limitations according to related issues. Haven't checked the details |
Yes, upstream's visit macro can significantly simplify the implementation. I'll try it. |
Note that |
I'll look into it. BTW, when taking redacting table names and column names into consideration, it becomes more complicated. That is, whether a type should be redacted also depends on its context. e.g. type |
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
9425213 | Triggered | Generic Password | f7fc8a5 | ci/scripts/regress-test.sh | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
This commit implements this idea, which customizes SqlOption's Display. It either redacts all options or none of them. As SqlOption's Display will redact by default, we need to explicitly call Statement::to_unredacted_string instead of Also added an e2e test. PTAL @xxchan @BugenZhao Table names and column names are not redacted in this PR, as explained below.
|
2e4d10e
to
8091858
Compare
@@ -61,7 +63,12 @@ fn read_rw_sinks_info(reader: &SysCatalogReaderImpl) -> Result<Vec<RwSink>> { | |||
.to_uppercase(), | |||
sink_type: sink.sink_type.to_proto().as_str_name().into(), | |||
connection_id: sink.connection_id.map(|id| id.connection_id() as i32), | |||
definition: sink.create_sql(), | |||
definition: if sink.owner.user_id == user_id { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this (only showing raw SQL if the user is the owner) is a common behavior in other DBMS? Even so, I guess it would be based on the permission system but not simply determined by the ownership. cc @yezizp2012
In my personal opinion I would suggest adding a new column of redacted_definition
. Users are allowed to decide which form to reveal or share with us.
Ok(stmt.to_string()) | ||
Ok(stmt.to_unredacted_string()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I ask how you find all references of to_string
call on Statement
? That is to say, how could we avoid showing an unredacted string where we should redact it in the future or vice versa?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how you find all references of to_string call on Statement?
Most of them are found by test failure 🥵
how could we avoid showing an unredacted string where we should redact it
to_string or display are redacted by default.
or vice versa
Caller is responsible for explicitly using to_unredacted_string
. Similar to crdb's behavior: "everything gets redacted except for those bits which we know are safe"
go for risingwavelabs/rfcs#86 |
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Redact all SqlOption when
show create
and query system catalog. Implement this idea.This PR adds a helper function to redact identifiers, e.g. table names and column names, as well as with_option values, from CREATE TABLE/VIEW/INDEX/SOURCE/SINK/MATERIALIZED VIEW statement. ~~~Implementation details:
Statement
type that requires redaction, implementMasking
trait for them, which redacts the type in place. ThenMasking::mask
is called recursively from CREATE statement.Masking::mask
takes aMaskingContext
as input, which maintains a String to int mapping. It's used to keep the relation between identifiers globally. e.g. Using the sameMaskingContext
,CREATE TABLE table_foo (bar int); CREATE MATERIALIZED VIEW mv_foo as SELECT bar from table_foo
will be redacted toCREATE TABLE _1_ (_2_ int); CREATE MATERIALIZED VIEW _3_ as SELECT _2_ from _1_.
test_masking
for usage example.#12673
Checklist
./risedev check
(or alias,./risedev c
)Documentation
Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.