I have several users each of whom should have read-only rights to the large table but has read/wrtie rights to their own table(s) but not to each others table(s).
Adding to the complication, I want to give each RoR user the ability to write their own SQL statements against the large table as well as their own table(s). I have successfully implemented being able to have them enter sql statements and create results they can view and/or download. Doing that is not my question.
I want to make sure each of my “readonly” users can’t modify any tables they are not authorized to see and/or change.
So,I guess, I want to change Postgres roles within Rails. Any guidance would, of course, be appreciated.
In my little rails app generator project: https://github.com/dgleba/bashrail there are scripts for this. Even if you don’t use the scripts, they document exactly how to implement it in that case.
I looked through your code and I’m not sure you have answered my question.
Let me try to clarify. There is a difference between a Devise role and a Postgres role. A devise role will control access to Rails functionality. For example, one can restrict access to a Rails controller method using Devise.
Database roles are conceptually completely separate from operating system [and Devise!] users.
I think I need to do something like “sudo -i -u SomeOtherPostgresUserName” but I want to do it inside Rails so I can connect to databases as user SomeOtherPostgresUserName.
Can you share how you did the "give each RoR user the ability to write their own SQL statements "? I may want to do the same.
Here is the code I use. RalphSql.exec_sql is what you want. RalphSql.get_column_names_from_table is a function I find useful for other obvious purposes.
class RalphSql
def self.exec_sql(sql_text)
begin
# Return an array of records
return ActiveRecord::Base.connection.execute(sql_text)
rescue Exception => e
byebug if ralph_test_byebug
raise e
end
end
def self.get_column_names_from_table(postgres_table_name)
sql = %Q[SELECT column_name FROM information_schema.columns WHERE table_name = ‘#{postgres_table_name}’;]
# byebug if ralph_test_byebug
pg_result = RalphSql.exec_sql(sql) # pg_result.class == PG::Result
ret = pg_result.values
# byebug if ralph_test_byebug
ret
end
I _think_ I need to do something like "sudo -i -u SomeOtherPostgresUserName"
but I want to do it inside Rails so I can connect to databases as user
SomeOtherPostgresUserName.
I would look at
ActiveRecord::Base.establish_connection()
which accepts either an atom representing an entry in your
config/database.yml or a hash with DB login credentials.
Aside:
class RalphSql
def self.exec_sql(sql_text)
begin
# Return an array of records
return ActiveRecord::Base.connection.execute(sql_text)
I hope you really really REALLY trust the input from your users
and do very frequent backups
What's the convention here: top posting or bottom posting?
Whatever is appropriate for the message at hand. When making a number
of points wrt previous post then obviously inline posting is
preferable. Well it's obvious to me anyway.
I’ve never used it, but something like “SET SESSION AUTHORIZATION” looks like it would do what you want, mostly:
You’d set up a “superuser” in config/database.yml and then change to the lower-privileged specific user per-request.
Some potential problems:
the lower-privileged users must not have sufficient permissions to call “SET SESSION AUTHORIZATION” themselves or the security is an illusion
you’ll want to make 100% certain that connections get a “RESET SESSION AUTHORIZATION”, or a selected user’s authorization will leak into the next request (and fail, see the previous point)
you’ll need to somehow sanitize the incoming SQL to remove queries like “RESET SESSION AUTHORIZATION; DROP TABLE all_the_things” or the security is an illusion
I noticed you mentioned “their own tables” above; if you’re already committed to solutions where adding users is complex, you might want to think about separating things further. You could use a tool like pglogical:
To replicate only the large table to per-user Postgres DBs. Definitely NOT an appropriate solution for multi-tenancy with lots of users, but neither is table-per-user.
