Is there a way to grant on *.*, excluding mysql.*? I have a user that I want to have the routine privileges (select, insert, update, delete, create, drop, alter) in all production databases, including any new databases that other users might create. If I grant on *.*, then the mysql database is included, which effectively makes that user an administrator. I do not want that user to be an administrator. I just want that user to be able to manipulate all production databases, without the need to explicitly assign rights for each database.
I am looking for a MariaDB answer. I will write a script in perl to handle this if I need to, but this seems like something for which MariaDB should have a built-in capability.
In case it matters, I'm running MariaDB v10.2.12 on 64-bit Windows 7.
Related
I've hosted a web application (using Shiny, a R package for interactive web applications) on AWS EC2. I've also set up an authentication mechanism on the app with shinymanger(https://datastorm-open.github.io/shinymanager/). This authentication requires reading and writing from a sqlite database (database.sqlite) that stores user information (username, password, etc). In order to create new users in the authentication system, I need "write" permission, so I changed the permissions of the sqlite database with chmod 777
Screenshot of user permission of sqlite database
Question: The AWS server is only owned by one other person, but I'm worried that since the web application is hosted on a public IP address, bad people could infiltrate the sensitive data. Is this permission setting safe? If not, how do I change the permission setting so that I can still read, write, and do everything that 777 allows, but safer!
I notice that everything is run by ubuntu.
If you're worried about security, you will probably want to run something like:
600 (rw-------) <- rule of least permissions. As long as the file is owned by the same user that the sqlite application runs as, this will work.
660 (rw-rw----) <- safe, group extended permissions. Allows members of the file group to r/w. Probably not needed, but can be used if multiple things will need r/w.
700 (rwx------) <- flexible user. Allows all actions from the user owning the file. Probably more permissions than needed, but I'm not super deep into SQLite (from my understanding it should only need r/w?)
770 (rwxrwx---) <- flexible group. Same as extended group permission, just also allows execute. Probably more permissions than are needed.
The one thing I would not recommend, specifically for a DB with file security concerns is any world permissions. The third perm should remain 0 to keep the file locked down to at least user/groups.
If you're curious about the full 'best practice'- I would recommend making an application specific user, changing the owner of the directory and file to that application user, and then applying all permissions as x00 permission sets (700 for directories, 600 or 640 for files).
I would like to know after upsizing ms access database to sql server successfully with my user name in the domain and windows authentication and linking access tables to sql server tables,
for distribution this front-end to other users in the domain what i have to do? Is enough give a copy of the front-end to other users and defining their user names and permissions in the sql server? Or it needs some vba code in ms access for defining linked tables and ODBC connection?
Yes, if the ODBC driver you use is installed on users' machines - and, of course, Access is installed.
Table links don't change. If you didn't use Windows authentication, however, tables had to be relinked using each user's credentials.
In my MySQL database I have two kind of users
MySQL users, used to connect and access a database directly from a client such as MySQL workbench or any ODBC editor.
ASP.NET membership users + roles : used to provide login for my websites.
My situation:
When I login via a webpage using the ASP.NET user credentials. I want to create a temporary random MySQL user (assign privileges, set password etc) and give it to the currently logged in (asp.net user) to gain temporary access to the MySQL database.
I know, if ASP.NET user has root access to create users he also has complete access to the database. My problem is, I have to give the user name and password so he can connect from another client and access the database directly. (I don't want give him root access or permanent access)
Having said he can access from another client, I would like to restrict this according to his login status in my webpage. like when he logs out of my webpage the newly created MySQL user is marked as expired or deleted.
I assume this should be very possible but I cannot think of any starting point. Could anyone help me?
kind regards
krish
This is possible. You could use the create user and grant syntax to create your user and grant them privileges.
You would however need to maintain a separate table for mapping MySQL users with an expiry date.
Have you thought about a different solution?
it would be vastly more work to complete but in the long run might be a more stable / reliable and scalable solution.
Maybe create your own WCF proxy for MySQL using NET.NCP, you could then have local user accounts / temporary accounts managed by you that authorise against your WCF service rather than the database directly, the proxy would in turn would connect directly to your database. This solution would also work from 3rd party applications.
Using a custom proxy would give you much greater control such as:
Being able to log SQL for specific users Sanitise or restrict any
specific command you don’t want executed on your database Not having
your MySQL server directly contactable on the internet
Split read & writes to different servers or clusters when scaling out
Edit 1: as per comments below:
I wouldn’t recommend relying on an event for the session end as this isn’t always fired. I would suggest you create another table to manage the users and their expiry.
For example, a table that holds the user ID or username and host along with an expiration time. This could be either date time / integer (epoch) depending on your requirements.
You would then need to invoke a query to identify all accounts from this table that have expired, you could then delete the user accounts from MySQL.
Depending on your MySQL version you could wrap a lot of the logic into a few stored procedures which will make the querying and maintenance overhead easier
I'm in the process of creating a simple ASP.NET Details and Grid View in two separate pages for simple record keeping. The Details View will be leveraged to enter records into the database and the Grid View will be leveraged for any updating of these records. I should note that I have only 'Windows Authentication' enabled on my IIS server.
One of the features I'm adding is audting when records are inserted or updated into the database. I'm using the CURRENT_TIMESTAMP command in SQL Server 2012 to enter when records are inserted and/or updated. However, I'm attempting to write which active directory user updated or inserted a given record. I first attempted to leverage the SYSTEM_USER command but all that writes to the database is the SQL server service acccount or dbo account which is unacceptable. I understand why the SQL Server service account is being written but what I need is to have the current Active Directory user's name be written to the 'username' field as noted below.
Here's the commands I'm using right now for the timestamp and username (this isn't the exact SQL command I'm using):
INSERT INTO <table-name> ([timestamp], [username]...) VALUES (CURRENT_TIMESTAMP, SYSTEM_USER...)
UPDATE <table-name> SET [timestamp] = CURRENT_TIMESTAMP, [username]) = SYSTEM_USER WHERE.....
What is the best way to get the current Active Directory user's name written to the 'username' field whenever they insert and/or update a given record and not the SQL Server Service account's credentials?
Thanks in advance!
How are you connecting to SQL Server? Are you connecting using SQL Authentication or using Windows Authentication?
If using sql auth, then there isn't a way without passing that information along with the database command (query).
If you are using Windows Authentication, are you impersonating the user in ASP.NET? If not, then it's the same problem as sql authentication.
If you are using impersonation in ASP.NET, then SYSTEM_USER should get you what you need.
If your website is using forms authentication a user store other than AD, then you'll have the same problem as sql auth.
Think of it this way: Is SQL Server aware of the user of the website? In most cases, no, unless you are using impersonation with windows auth or you are telling SQL Server the user name (i.e. passing it in with your command statement).
You could store the application username on the context_info variable. And afterwards retrieve it in your trigger or anywhere you need it.
You should do this before each connection to sql is made; should be easy to do, since usually you have the code for the connection in one place only.
I’m using .Net 3.5 and SQL Server 2008 Express.
Should I use the administrator user for the connection string,
Or should I create a new user with limited permissions?
If I need to create a new user for the connection string:
What security permissions should I grant him?
How do I set those permissions?
Thanks.
You must definitely create a specific SQL login, which you will use for database hits in your application.
Access only to the database it uses.
Assign specific write/read permissions according to the logic you have.
Never use Admin users account. Decide what all permission is required by your application then create the user based on that. I dont work mostly with SQl servers but I don't think there is a definite rule for this. It depends on application and the situation.
if the application is used to display only records then grand only read access.
Please check this post too
Enterprise Connection String Management in ASP.NET - Best Practice?
never use the sysadmin (sa) account - EVER!! create a new account, probably start with a member of the Public group, which is the default and then work from there.
Also, do not embed the pwd in the connection string - rather make it part of a config file; not only is it more secure, it's easier to manage.
In fact, you should really store the entire connection string in a config file.