I would like to create a MySQL user with permissions to create and remove other users, but prevent my own (superuser) account from being deleted or modified.
The user seems to need CREATE USER to be able to manage users, and this seems to allow deletion of all accounts.
Goal is to provide MySQL as a service with the possibility to do some user management, while keeping an administrative user on the database protected from users.
Edit: Users will be connecting to MySQL directly using the CLI mysql client or a third party database tool. Of course this problem could be eliminated by providing the user a custom system to do user management and do custom access control in there, but I'd prefer to give direct access to the DB.
MySQL does not provide this level of control over user management. But I can imagine a small application of your own that would let your authorised users to manage only users you allow.
Only the application would connect to the database as a privileged user.
Only the application would issue the actual CREATE USER and DROP USER statements, and only on accounts that you allow.
Having manipulated these actual MySQL system users via this application, these accounts would become available for direct connection.
Related
I have created a database with two tables on my phpMyAdmin account, and I'm using 000webhost for a web hosting. Once I logged out of my account, and re logged in, everything was deleted. Does anyone know how I can save the database I have re added? thanks so much
Normally a database would persist across login sessions. The only possible exception would be if you log in as different users (which could be different usernames or if you use fine-grained IP-based access controls, for instance, two different users both with username natasha, one host 192.0.2.1 and another with host 192.0.2.50). If those users don't have full access, they might not be able to see the database owned by the other user.
Other than that, I can't think of any reason your data wouldn't persist and suggest you contact your hosting provider's support for further assistance.
If I have a database "Movies" and I have 3 different users I created using the
Create User... identified by ... "
command. Users are "A" "B" "C" with different roles, and a table inside this database called "users" where I save username and password.
Can I use these MySQL user accounts (A, B or C) in the web application "login.php" since they are not saved in the table "users".
There are several types of user in most web applications.
The easiest to explain are "application users" - when you sign up for Facebook, or Github, or Amazon, or indeed Stack Overflow, you create an application user profile. This profile can have all sorts of attributes, and may have rights within the application - for instance, on Stack Overflow, some people have rights to edit questions. These rights apply to application domain concerns (like "question" in Stack Overflow).
The other type of user is "infrastructure user" - the credentials used to authenticate and authorize applications in the infrastructure that runs your application. These users have rights at the infrastructure level - in your database, those rights may include select, insert, create table etc.
Its almost never a good idea to have your application users mixed with your infrastructure users. You almost certainly don't want someone logging into your web application who can drop your database.
If you really need to do this, you have to modify your connection string, and log in as the infrastructure-level user.
I am trying to setup ejabberd as IM solution for my project, which will be mobile app + backend. I am using SQL auth (and SQL store for all modules also), using MSSQL via ODBC. I have some questions I didnt find answered in docs.
Do I understand correctly, that ejabberd is multi-tenant (since it can support multiple domains). If so, how are users assigned to particular tenant (domain)? In users table in DB, there is only username (without domain part). Can I have two different users john#jabber.myproject.com and john#jabber.myotherproject.net ?
I want to create XMPP accounts on ejabberd automatically (user doesnt need to know anything about underlaying service) - do I need to register users via API, or can I insert rows directly into DB table users and ejabberd will be OK with it?
In users table in DB, there is only username (without domain part). Can I have two different users john#jabber.myproject.com and john#jabber.myotherproject.net ?
Create a new database for each vhost, and use the host_config option in ejabberd.yml to tell which database to use for each vhost:
https://docs.ejabberd.im/admin/configuration/#database-and-ldap-configuration
Or you can enable the new SQL schema, see https://blog.process-one.net/ejabberd-18-03/
do I need to register users via API, or can I insert rows directly into DB table users and ejabberd will be OK with it?
Both are acceptable. In the second case, there are chances that some task performed at account registration is missing in your server, but I don't remember any module that performs any task at account registration. So, it looks OK.
Suppose you're writing a simple database web application using Ruby and MySQL. Access to the database is controlled by Ruby code. The user name that the Ruby code uses to access the data is the only regular user on the database. Does it make sense for that user to be "root"? Or is there any extra security in creating a second user just for the application?
Simple, consider the root as the main user, who can do everything (by default).
If he wants to dump the whole database, he can, if he wants to create some data to create (for example) fake account to overpass your bank system, he can.
So if your code is not enough secure (and this is quite often usually), you have strong security issue.
Usually, "a basic" security (really basic), should looks like that :
create a simple user, give him (with GRANTS) the right to SELECT, INSERT, UPDATE and DELETE on a specific database.
create another user who can SELECT and lock tables and SHOW VIEWS to perform dump (database save).
On a more "complex" system, you should create many users, depending of what they should access, this is for simple reason : if somebody got a SQL injection access, if the user can only access to a single view (for example), and not the whole database, this is a security issue but not the baddest one...
Also view are often used for that...
And finally don't forget triggers if you want (for example a log table), to disable insert or update or delete on a table, for everybody (except somebody who can destroy trigger of course) :
Use a trigger to stop an insert or update
Besides editing or deleting all data in your database, the root user also have the FILE privilege which gives access to:
LOAD DATA INFILE which can be used to read any file on the server machine.
LOAD DATA LOCAL INFILE which can read files on the client machine (the web server machine).
SELECT ... INTO OUTFILE which can create files on the server machine.
This is why your application should have only the privileges it needs, and this is also the reason your MySQL server daemon should be run as a non-privileged user on the server machine.
See also General Security Issues in the manual.
If everybody/thing is root, you lose auditability, you lose the ability to restrict the app to stop attacks (i.e. your app doesn't need this segment of sensitive information, seal it away from its user). If somebody compromises the app, you can suspend the account etc.
I would not make a user "root".
I'd create a separate username and password just for that application and GRANT it only the permissions required to do its job.
I would create a new user, giving it only the permissions it needs (SELECT, UPDATE, INSERT and DELETE usually do the trick). Like that, you limit the ability for the code to be manipulated in an unintended way.
"root", or generally speaking, users with Super User privileges, can change passwords, delete accounts, and therefore prevent you from accessing your own database.
If you server hosts only one application, then you may not need to create several lesser privileged accounts. However, it is common practice to create at least one user for each application, so that if one application gets compromised, other applications (and underlying data) may not be.
I'm thinking of writing a CouchDB-backed application that will store sensitive data. Is it possible to set things up so that I can get something like MySQL's and PostgreSQL's access control, where particular users on the system (users in the sense of Unix system users) can be denied or granted access to a particular CouchDB database?
Absolutely, you can set up users in the _users database. You can assign roles, groups, as well as any other custom fields for each user. In the validate_doc_update function in your design document(s), you can check user roles and approve or deny access based on that. You can also globally assign users as "readers" and "writers". You can authenticate users via Basic HTTP Authentication, OAuth and a variety of other methods.
Refer to the Security Features Overview and Document Update Validation pages on the wiki to get started.