Like many hosting providers, we grant full access to databases for site administrators, and we create a separate, rights-limited user for each database. This is a great idea until it's time to run update.php. It really should detect that I don't have DROP, ALTER, etc; but instead it just fails badly. What I've been doing is editing settings.php to replace the credentials in $db_url, running update.php, and then re-editing the file. I'm sure that most of our users are just leaving things as-is, which is bad for many reasons. It would be nice to have a place to enter some temporary credentials, stored in $_SESSION and disposed of when the user logs out. a) Is this in-progress someplace? b) Anybody have UI suggestions for this? It could just go into update.php, but may have use elsewhere. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
Allie Micka wrote:
Like many hosting providers, we grant full access to databases for site administrators, and we create a separate, rights-limited user for each database.
This is a great idea until it's time to run update.php. It really should detect that I don't have DROP, ALTER, etc; but instead it just fails badly.
What I've been doing is editing settings.php to replace the credentials in $db_url, running update.php, and then re-editing the file. I'm sure that most of our users are just leaving things as-is, which is bad for many reasons.
It would be nice to have a place to enter some temporary credentials, stored in $_SESSION and disposed of when the user logs out.
Great idea, Allie. This would be a good step towards improved security as well as more reliable updates. I believe update.php should definitely check that it can issues ALTER, DROP, etc. if at all possible before trying to update tables. ..chrisxj
Chris Johnson wrote:
Allie Micka wrote:
Like many hosting providers, we grant full access to databases for site administrators, and we create a separate, rights-limited user for each database.
This is a great idea until it's time to run update.php. It really should detect that I don't have DROP, ALTER, etc; but instead it just fails badly.
What I've been doing is editing settings.php to replace the credentials in $db_url, running update.php, and then re-editing the file. I'm sure that most of our users are just leaving things as-is, which is bad for many reasons.
It would be nice to have a place to enter some temporary credentials, stored in $_SESSION and disposed of when the user logs out.
Great idea, Allie. This would be a good step towards improved security as well as more reliable updates. I believe update.php should definitely check that it can issues ALTER, DROP, etc. if at all possible before trying to update tables.
This is an excellent idea. It would be a nice addition to the database API. I looked at the MySQL documentation for a bit and didn't notice anything particularly useul. SHOW GRANTS shows things for the current user, but not inherited permissions. And the output is in multiple rows of strings that have to be parsed. How are things looking on Postgres and SQLite? -- Neil Drumm http://delocalizedham.com/
I looked at the MySQL documentation for a bit and didn't notice anything particularly useul. SHOW GRANTS shows things for the current user, but not inherited permissions. And the output is in multiple rows of strings that have to be parsed.
How are things looking on Postgres and SQLite?
instead of parsing, i suggest just trying the operation (create table, alter, etc.). thats guaranteed portable.
Neil Drumm wrote:
Chris Johnson wrote:
Great idea, Allie. This would be a good step towards improved security as well as more reliable updates. I believe update.php should definitely check that it can issues ALTER, DROP, etc. if at all possible before trying to update tables.
This is an excellent idea. It would be a nice addition to the database API.
I looked at the MySQL documentation for a bit and didn't notice anything particularly useul. SHOW GRANTS shows things for the current user, but not inherited permissions. And the output is in multiple rows of strings that have to be parsed.
How are things looking on Postgres and SQLite?
Perhaps it would be possible to simply test permissions by trying an operation and seeing if it fails. For example, to test ALTER, just ALTER a column to itself (i.e. no changes). DROP is a problem, since it's destructive unless you can CREATE to make a backup first. It might be possible to derive permissions with a carefully ordered set of such tests. ..chrisxj
On Jan 24, 2006, at 10:33 AM, Allie Micka wrote:
Like many hosting providers, we grant full access to databases for site administrators, and we create a separate, rights-limited user for each database.
This is a great idea until it's time to run update.php. It really should detect that I don't have DROP, ALTER, etc; but instead it just fails badly.
What I've been doing is editing settings.php to replace the credentials in $db_url, running update.php, and then re-editing the file. I'm sure that most of our users are just leaving things as- is, which is bad for many reasons.
It would be nice to have a place to enter some temporary credentials, stored in $_SESSION and disposed of when the user logs out.
a) Is this in-progress someplace? b) Anybody have UI suggestions for this? It could just go into update.php, but may have use elsewhere.
I am definitely interested in this. With the latest release candidate for CivicSpace we have now included security checks on configuration files to ensure that files written to in the installation should now be locked down on the webserver. It would make sense to evolve these same sorts of protections for update.php. No ideas on implementation, but interested in continuing the conversation to make this happen. Cheers, Kieran
Allie Micka pajunas interactive, inc. http://www.pajunas.com
scalable web hosting and open source strategies
It would be nice to have a place to enter some temporary credentials, stored in $_SESSION and disposed of when the user logs out.
Interesting. Perhaps we should let users specify a different $db_url in settings.php that is used while updating. If not specified, we use the usual $db_url. How about this pseudo-code in update.php? global $user, $db_url, $db_url_updating if ($user->uid == 1) { $db_url = $db_url_updating; }
On Jan 24, 2006, at 2:48 PM, Moshe Weitzman wrote:
It would be nice to have a place to enter some temporary credentials, stored in $_SESSION and disposed of when the user logs out.
Interesting. Perhaps we should let users specify a different $db_url in settings.php that is used while updating. If not specified, we use the usual $db_url. How about this pseudo-code in update.php?
global $user, $db_url, $db_url_updating if ($user->uid == 1) { $db_url = $db_url_updating; }
It's an OK workaround, but I'd rather see fields where users can optionally supply a username/password. In our case, multiple people have admin rights on a db, and it would be bad form for one of them to hard-code their creds. You could add this to the update.php page, but it's not very global reusable from there. More importantly, the settings.php route doesn't protect you if someone can view that file in some way. Ideally, there should be no place where admin creds are permanently stored. One approach might be to create a "supply administrative credentials" permission. Then, when a page/module needs to do advanced stuff, it would use some sort of db_escalate function: function db_escalate($rights) [ if !user_access('supply administrative credentials') return; if current db connection has appropriate $rights, return; if new username/password have been supplied, add to $_SESSION if isset($_SESSION[username] and $_SESSION[password] reconnect to the db return form for changing creds, populated with $_SESSION ] Each advanced-rights page would show a new creds box, and the supplied creds would persist through that user's session. The function could also notify Drupal that the present connection won't work, and things might be disabled appropriately. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
On Tue, Jan 24, 2006 at 03:48:19PM -0500, Moshe Weitzman wrote:
Interesting. Perhaps we should let users specify a different $db_url in settings.php that is used while updating. If not specified, we use the usual $db_url. How about this pseudo-code in update.php?
global $user, $db_url, $db_url_updating if ($user->uid == 1) { $db_url = $db_url_updating; }
I think this is the best way, but with small modification: if (we are in update.php) && ($db_url_updating is defined)) { $db_url = $db_url_updating; } Site admin knows if the user which is normally used for connecting to the db has necessarily rights or not. If he does not have them, he should tell drupal which user/password use for update operations. Simples, most portable, solving all problems IMO. The only problem is that user/password for such "powerfull" user is written in the file. Some people might want not to store it on disk, but input only when updating. So a form in update.php would be needed. But is it really needed? If someone could read the information and e.g. drop all tables - he could also just DELETE from all tables. So it's not really safer to not write them in the file. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
Allie Micka wrote:
This is a great idea until it's time to run update.php. It really should detect that I don't have DROP, ALTER, etc; but instead it just fails badly.
The modules page will probably do these queries at some point in the future. -- Neil Drumm http://delocalizedham.com/
Neil Drumm wrote:
Allie Micka wrote:
This is a great idea until it's time to run update.php. It really should detect that I don't have DROP, ALTER, etc; but instead it just fails badly.
The modules page will probably do these queries at some point in the future.
true, though that doesn't affect the issue that allie describes
I haven't had time to do anything like this, but I did request the feature! http://drupal.org/node/40121 -Dave On Tuesday 24 January 2006 10:33 am, Allie Micka wrote:
Like many hosting providers, we grant full access to databases for site administrators, and we create a separate, rights-limited user for each database.
participants (7)
-
Allie Micka -
Chris Johnson -
Dave Cohen -
Kieran Lal -
Moshe Weitzman -
Neil Drumm -
piotr＠mallorn.ii.uj.edu.pl