Usage instructions
db-readonly is a skill specially designed for data security scenarios, aiming to provide users with a zero-risk database query experience. It uses a strict SQL whitelist mechanism and environment variable management to ensure that only read-only operations can be performed on PostgreSQL and MySQL databases, fundamentally eliminating the risk of accidentally deleting data.
Core usageIn terms of performance, this Skill establishes a database connection by reading standard environment variables (such as PGHOST, PGUSER, PGPASSWORD or MYSQL_HOST, MYSQL_USER, etc.), and only accepts three types of SQL statements: SELECT, WITH, and EXPLAIN. Users canscripts/db_readonly.shThe script directly executes the query, or exports the results to CSV, TSV, or JSON format for subsequent analysis. For example, executescripts/db_readonly.sh postgres "SELECT * FROM users LIMIT 100" --format csv --out /tmp/users.csvData sampling and export are completed.
Significant advantagesThis is reflected in its multiple safety protection design. First of all, regular expressions are used to strictly filter SQL statements, explicitly blocking all write operations such as INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, TRUNCATE, etc., and forcing read-only operations at the code level. Even dangerous commands entered by mistake will be intercepted. Second, sensitive credentials are injected entirely through environment variables, eliminating the risk of hardcoding passwords or leaking command line parameters. In addition, the script implements complete error handling and parameter verification, usingset -euo pipefailEnsure robustness and provide clear prompts when environment variables are missing or parameters are incorrect.
potential disadvantageslies in functional limitations. This skill only supports PostgreSQL and MySQL, and will not work with MongoDB, SQLite, or other databases. At the same time, it relies on the system's pre-installed psql or mysql client tools, and requires users to manually configure a series of environment variables, which has a certain configuration threshold for novices. In addition, as a purely read-only tool, it naturally cannot meet database operation and maintenance needs such as data writing and Schema changes. If you encounter such needs, you need to use other tools.
Suitable target groupMainly include: database administrator (DBA) to conduct daily inspections, capacity assessment and troubleshooting; data analysts to extract data samples for exploratory analysis (EDA); back-end developers to verify data status or debug complex query statements; and operation and maintenance personnel to generate regular data reports. Any technical staff who need to frequently view production environment data but strictly avoid misuse will benefit from this.
Risks of useMainly focus on performance and configuration. Since the tool itself does not set a hard limit on query complexity, if users execute a full query on a large table that lacks WHERE conditions or LIMIT restrictions, it may lead to exhaustion of database server CPU/IO resources, network transmission timeout, and even affect the stability of the production environment. It is recommended to always follow the "small steps and fast" principle and first explore the data size through COUNT or LIMIT 10. Additionally, although credentials are managed through environment variables, the user still needs to ensure that the shell configuration file (e.g..bashrc) or set variables in the startup script with appropriate file permissions (such as 600) to prevent local credentials from being read by other users.
Safety review
Core usage
db-readonlyIt is a CLI tool that focuses on secure database read-only queries and supports the two mainstream databases PostgreSQL and MySQL. After users configure connection information through environment variables, they can execute three types of query statements: SELECT / WITH / EXPLAIN, and the results can be exported to CSV/TSV/JSON format.
Basic operations
- PostgreSQL:
scripts/db_readonly.sh postgres "SELECT now();" - MySQL:
scripts/db_readonly.sh mysql "SELECT NOW();" - Export CSV:
scripts/db_readonly.sh postgres "SELECT * FROM users LIMIT 100" --format csv --out /tmp/users.csv
Connection configuration
| PostgreSQL | MySQL |
|-----------|-------|
|`PGHOST`, `PGDATABASE`, `PGUSER`, `PGPASSWORD`, `PGPORT` (default 5432)|`MYSQL_HOST`, `MYSQL_DATABASE`, `MYSQL_USER`, `MYSQL_PASSWORD`, `MYSQL_PORT` (default 3306)|
---
Significant advantages
1. The security boundary is extremely clear
Adopt a regular expression whitelist mechanism to rigidly intercept all non-read operations such as INSERT/UPDATE/DELETE/DROP/ALTER, eliminating the risk of misoperations from the code level. Script enabledset -euo pipefailStrict mode, error handling specifications.
2. Zero external dependency attack surface
Relying only on the system's native tools (psql/mysql), with no third-party packages, no dynamic loading, and no network API calls, the risk of supply chain attacks is close to zero.
3. Privacy compliance meets standards
No sensitive user information is collected, and database credentials are only injected through environment variables, complying with GDPR/CCPA data minimization principles.
4. Credible sources
Hosted in the openclaw GitHub organization repository, author ryanhong666 is an active developer, version management specification (semantic v1.0.0).
---
potential limitations
- Single function: Only supports read-only scenarios. Any data modification needs to switch to other tools or manual intervention.
- No audit log: The current version does not record query history and cannot trace the operation track.
- No hard limit on the number of rows: Rely on users’ conscious compliance
LIMITSuggestion, very large result sets may cause memory pressure - Annotation injection risks: The current regular expression does not explicitly filter the SQL comment syntax, which theoretically exists
--or/* */Bypass possible (low risk in practice)
---
Suitable for the crowd
- data analyst: Quickly explore table structure, sample data, and generate reports
- Operation and maintenance engineer: Online troubleshooting and performance diagnosis (with EXPLAIN)
- Developer: Data verification and debugging in local development environment
- Security sensitive scenarios: Production environment data query that requires strict read-only permissions
---
General risks
|Risk type|illustrate|Mitigation measures|
|---------|------|---------|
|Credentials leaked|Passwords in environment variables may be leaked by the process|Use a dedicated read-only account, the principle of least privilege, and avoid clear text storage.|
|Large query drag database|`SELECT *` No LIMIT may result in full table scan|Force LIMIT, disable `SELECT *` on huge tables|
|network sniffing|Transport exposure when database connection is not encrypted|Configure SSL/TLS connections, use private networks|
---
CLS-Certify security certification: S level (100 points), T2 source credibility
databasedata-analyticsbackenddevopsproductivity
Copyright and takedown notice: AI Islands curates this page from public information. Skills, code, documents and packages remain the property of their original authors or rights holders. This listing is provided for indexing, research and installation convenience. If you believe any listing or download link infringes your rights, contact ai-islands@streamflowintel.com with proof of ownership, relevant URLs and your request. We will review and remove or adjust the content promptly. Review package permissions, dependencies and safety risks before installing.