Please help me with my case.
We have SAP HANA implemented in our company.
There were few custom roles created based on this doc provided by SAP:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c02c2004-899d-3110-8488-b3ff8362bbf6?QuickLink=index&overridelayout=true&59180354403522.
We have few test users created with different roles assigned (like: transport executor, transport manager). What is the recommended way for testing if these roles are properly configured?
We were thinking about XSUnit, but we have no clue what checks should be performed in order to verify the priviliges.
Is this approach proper?
Checking privileges is a bit tricky.
Since the 'proof of the pudding is the eating' to properly test if your privilege setup is working as expected, you would need to
set up a user
set up your role
assign the role to the user
logon as or impersonate the user so that the role becomes the current role and therefore the current execution privilege setting
try to do whatever the role allows --> this should obviously work
try to do things that shouldn't be possible with the role --> here you should receive the right error messages
tear down everything afterwards
There is nothing build into SAP HANA for that. And depending on what kind of privileges should be tested, it might be difficult to test all of them (dropping tables, deleting DBs, shutting down the system... all that is not easy to contain in a single unit test).
So, I'd recommend to use system views EFFECTIVE_PRIVILEGES and EFFECTIVE_ROLES instead and just check for operations that are allowed once the to be tested role has been granted.
Lars
Related
I'm trying to create users in MarkLogic that have permissions to given databases. I read Security Guide from MarkLogic docs page and found that you can set permissions on given URIs, Collections or functions.
Permissions on collections can help me with marking given collections from database as readable only for given set of users, but still other users can create and modify documents in different collections (or create documents without collections).
For e.g.
I have two databases:
Test
Test2
And two users:
UserTest
UserTest2
How can I set permissions that UserTest will have permissions read/update/insert/execute on database Test and can't modify or read anything database Test2?
Each database can be associated with a dedicated security database. The way you describe your use case ("UserTest will have permissions read/update/insert/execute on database Test and can't modify or read anything database Test2"), you might want to consider dedicated security databases for the Test and Test2 databases.
The other way would be to use different document permissions for roles for the two databases. You can set read/update/insert/execute permissions at document level for a given role at insert time, or change them with xdmp:document-add-permissions() (retains previous permissions) or xdmp:document-set-permissions() (overrides previous permissions) after insert. For instance, you could have a role Test-Reader for database Test and a role Test2-Reader for database Test2, and ensure that (1) your UserTest user has the Test-Reader role (but not the Test2-Reader role), and (2) that all documents inserted into the Test database pair the read capability with the Test-Reader role (but not the Test2-Reader role) etc. (Same for the other capabilities.)
If controlling this explicitly sounds like a lot of work, note that default document permissions can be declared to apply implicitly both at the user and at the role level.
Finally, if you set no permissions at all during document insert (and if no implicit/default permissions are defined at user or role level), only users with the admin role can read/update/insert/execute.
Here's the relevant section for document permissions from the Understanding and Using Security Guide: https://docs.marklogic.com/guide/security/permissions#id_85471
There is no user-level specifications for a database. But keep in mind, a database is not accessible on its own - it is accessible by way of an application(s) which is linked to particular database. Unless you allow people to run eval and allow them to eval against another database, then you application will keep people within the specified database. (Note: ML8 Advanced HTTP server changes this a bit because you can switch database on-the-fly per request- but the rules about being stuck to a single database still stands).
The only other item I think is useful to you is the ability to define which URI prefixes a user can write to, but that does not negate the fact that the application level decided which DB is being accessed.
From what I read so far, the WL 6.1 documentation does not much care of this, and it's assumed that database user ID is SYSADM or something like that. Also, I did not see any explicit explanation what privileges the user ID must have.
While SYSADM is fine for development or staging environment, for production is desired to allow the DB user as less as possible, on the other hand I don't wish to get some exceptions related to weak permissions.
Is there any documentation or other source which explicitly mentions/explains what permissions DB2 user ID must have for Worklight 6.1 datasources?
UPDATE: My understanding is that for WL application work (not install) must be used a separate DB user (mostly for security reason, give as less as possible permissions in production). My question above refers to that "application" DB user. It's clear that create tables and schemas activity can do any DB ID, including SYSADM, which is overkill to further work.
I am asking about DB2 user which configured in WAS datasources, once someone else created DBs, schemas and tables.
The DB2 user used to connect to the datasources need not have any special privileges other than to be able to connect to the Worklight databases. The DB2 user that is used to actually create and initially populate the databases must have SYSADM or SYSCTRL privileges, but these are not needed once the database is set up.
There is more information in the documentation, here: Creating the DB2 databases
The documentation defines the privileges required for a user that can create the tables at install time, upgrade the tables for a new Worklight version and use them at runtime.
At runtime, you need, for each table created: SELECT, UPDATE, INSERT, DELETE. And you need to be able to select a SEQUENCE.
The list of tables and SEQUENCE for Worklight can be found in
/WorklightServer/databases/create-worklight-db2.sql and create--worklightreports-db2.sql
So I wanted to know if there is an acceptable method to Allow SQL Injection.
Example:
Limit permissions on the table(s)/database(s)
Why you ask?
My employer wanted to devise a way to test the skills of applicants, one suggestion was to allow resume submissions via SQL Injection.
Any thoughts? suggestions?
You could use roles. Create a role for the web application (or whatever) that is used to connect to the database. Limit this role to only permit INSERT and access to necessary tables for applying. Applicants with access to your database through the application could then only use SQL injections to add their resume.
It may be possible for someone more talented in SQL to use injections in a way that increases the role's permission. But I think if the role had limited access to only specific tables and didn't have CREATE or GRANT privileges, the user wouldn't be able to create new roles.
Here is some information on roles to get you started:
Adding Roles to MySQL with MySQL Workbench
Creating Roles in PostgreSQL
GRANT command - used to add privileges to users on table, database, etc. This page is for PostgreSQL, but MySQL is very similar (see this SO answer)
Given that the reason behind this is to test people's ability, create a database with data you can afford to lose. Set up a form that posts to a coldfusion or php or java or .net or some other type of page which connects to that database.
On the form, put a textarea and submit button. On the form target page, log what they put in the textarea. Compare the log to the database to see how it turned out.
Then test to your heart's delight.
I installed postgreSQL by default with apt-get and I believe it has automatically added a user for me called "postgres".
I only have one database that I want to sort on postgres, so is
there any point creating another user account for this database or
should I just keep with the one which is installed with postgreSQL
"postgres"?
The user account postgres which is made for me, is it given some
kind of default password? Is it recommended that I put in my own
password?
EDIT: I misinterpreted the question, the OP is asking about internal users, not system users
Original Answer: System users for running servers
Most services running on a linux box are given their own independent user, as a standard security practice. In the off-chance that the postgreSQL server was compromised -- either you made a mistake, or there was a vulnerability in postgresql, or whatever -- the attacker can only gain access to the resources allowed to the user running the postgresql server. If that user is root, you lose the machine. If that user is your user, you lose not quite as much. If that user is postgres, which only has minimal access to anything.. you lose the database, and that's all.
So:
You merely need a single user for the postgreSQL server, regardless of what, exactly, that server process is hosting. If (it sounds like one was) a user was created for you automatically, you're all set with this step. If you need to make one manually (sounds like you don't), you would also have to change the permissions so that the new user can access only what it needs to.
That account very possibly cannot be directly logged into; if it has a password at all it's a lot of random data. In order to use the account, you need to start out as root, and then voluntarily "downgrade" yourself to postgres. In the case of the server, root starts the server "under the name of" postgres. I would advise leaving it alone.
Second Answer: Database users
Once you have a server running, the server will keep its own set of users, for the purposes of accessing the database. The simplest architecture you could use there is just having a base user with full permissions do everything. While this works, it is not advised if you are hosting this externally. A more preferable solution is to have a set of users, similar to how the OS is set up: a bunch of users to do specific tasks, and one admin user to rule them all. That said:
You don't have to, but if you are going to host this anywhere (if you're not just using it for personal things, and it's world-accessible), I would advise extra users with limited permissions.
http://archives.postgresql.org/pgsql-admin/2001-10/msg00192.php
There is no password by default; create one with ALTER USER.
Passwords do not take effect unless pg_hba.conf is set up to use them. If
it is, and you have not assigned a password to postgres, you will not be
able to connect as postgres.
re 1)
the default database user that is created during installation is a "superuser" and for the same reason you should not do your daily work as "root", you shouldn't work with a superuser in a DBMS. So the answer is a clear: yes, do create a second user. You can grant that role all privileges on the default database (also called postgres), so that you don't need a second database.
More details on how to create a user and how to grant privileges can be found in the manual:
http://www.postgresql.org/docs/current/static/sql-createuser.html
http://www.postgresql.org/docs/current/static/sql-grant.html
re 2)
I don't know Linux that well, but usually you should have been asked for a password during installation. At some point in the installation a new data directory is initialized using the command initdb which requires a password to run.
If you don't know the password, you log into the postgres linux account, then you can probably run psql without specifying a password. That enables you to reset the database password and create a new user.
More details about users and authentication are in the manual:
http://www.postgresql.org/docs/current/static/client-authentication.html
http://www.postgresql.org/docs/current/static/user-manag.html
I have a large web application that relies on database (MSSSQL 2008) triggers to perform some of its functions. It offers a web-interface which allows the end user to make form-based changes to the database.
The issue is - when the web application is run with one userid in the apppool, the database triggers don't get triggered (they have logging functionality which enables me to see that); but if I change the userid in the AppPool to another username/password, these triggers are executed. Note that the table updates are performed in both scenarios. This is the only difference I can spot between the system behavior under the two different circumstances. Both users have dbo privileges, and are able to read/write into the database.
Any thoughts on what may be causing this?
Thanks.
*UPDATE:
Neither user is sysadmin; this happens for ALL of my database triggers. *
*UPDATE #2:
After digging more into the problem, I found out that the logging function was relying on a queue (yes, I know) that has inconsistent behavior for the two user accounts. To me this means that the permissions for both accounts are somehow mismatched and that is most likely the root of the problem. *
This turned out to be a nondescript permissions error for that particular user account. When the account was removed from the database and added back in - the triggers, logging, and all related events started working appropriately.