Add pgvector as default KB store

[hamishfagg]

Adds a pgvector container and uses it as the default KB store. Requires building our own pgvector container in order to include an init script that ensures DBs are created.

[entelligence-ai-pr-reviews]

Entelligence AI Vulnerability Scanner

Status: No security vulnerabilities found

Your code passed our comprehensive security analysis.

[entelligence-ai-pr-reviews]

Review Summary

🏷️ Draft Comments (4)

Skipped posting 4 draft comments that were valid but scored below your review threshold (>=13/15). Feel free to update them here.

docker-compose.yaml (1)

19-27: depends_on healthcheck condition for pgvector is specified, but pgvector service lacks a healthcheck, causing mindsdb to potentially start before pgvector is ready, leading to connection failures.

📊 Impact Scores:

• Production Impact: 4/5
• Fix Specificity: 5/5
• Urgency Impact: 3/5
• Total Score: 12/15

🤖 AI Agent Prompt (Copy & Paste Ready):

In docker-compose.yaml, lines 19-27, the `pgvector` service is referenced in `mindsdb`'s `depends_on` with a healthcheck condition, but `pgvector` does not define a `healthcheck`. This can cause `mindsdb` to start before `pgvector` is ready, leading to connection errors. Add a `healthcheck` section to the `pgvector` service that checks PostgreSQL readiness using `pg_isready`.

---

init-dbs.sh (3)

23-26: create_database always attempts to create a database named 'kb' regardless of the argument, causing duplicate or unintended database creation.

📊 Impact Scores:

• Production Impact: 4/5
• Fix Specificity: 4/5
• Urgency Impact: 3/5
• Total Score: 11/15

🤖 AI Agent Prompt (Copy & Paste Ready):

In init-dbs.sh, lines 23-26, the create_database function always attempts to create a database named 'kb' regardless of the argument, which can cause duplicate or unintended database creation. Remove lines 23-26 so that create_database only creates the database specified by its argument.

---

39-39: $username and $userpassword are interpolated directly into SQL in CREATE USER, allowing command injection if attacker controls these values.

📊 Impact Scores:

• Production Impact: 5/5
• Fix Specificity: 2/5
• Urgency Impact: 4/5
• Total Score: 11/15

🤖 AI Agent Prompt (Copy & Paste Ready):

In init-dbs.sh, line 39, the variables $username and $userpassword are directly interpolated into a SQL statement, which allows for SQL injection if these values are attacker-controlled. Update the CREATE USER statement to properly sanitize or quote these variables to prevent command injection. Ensure that any special characters are escaped or rejected.

---

19-22: $db_name is interpolated directly into SQL in psql commands, allowing database name injection if attacker controls this value.

📊 Impact Scores:

• Production Impact: 4/5
• Fix Specificity: 2/5
• Urgency Impact: 4/5
• Total Score: 10/15

🤖 AI Agent Prompt (Copy & Paste Ready):

In init-dbs.sh, lines 19-22, the $db_name variable is directly interpolated into SQL, which allows for SQL injection if attacker controls this value. Use quote_ident or equivalent to safely quote the database name in the SQL statement.

---

[entelligence-ai-pr-reviews]

Review Summary

[entelligence-ai-pr-reviews]

Review Summary

[entelligence-ai-pr-reviews]

Review Summary

[ZoranPandovski]

I think this is handled by GRANT ALL PRIVILEGES ON SCHEMA public TO $username;

[ZoranPandovski]

Same here handled by GRANT ALL PRIVILEGES ON SCHEMA public TO $username;

[hamishfagg]

Are you saying we can get rid of?

GRANT ALL PRIVILEGES ON DATABASE $db_name TO $username;
GRANT ALL ON SCHEMA public TO $username;