Hi i have connected to oracle as a non dba user (ie, it has no 'dba' privilege).I tried to create an oracle JOB with this user.
But I couldn't. Is it possible to do it as a non dba user?
(Also ,before creating the Job i tried to get what's the current maximum id of existing JOBs.That also I couldn't)
You don't need DBA privileges to creae a job.
For further details check the Security Model chapter in the Oracle documentation:
DBMS_JOBS
DBMS_SCHEDULER
Related
We are on Enterprise - 6.1.0 and want to create a read only user. I've come across documentation that states we should be able to assign a Consumer role to this user, however there are no Consumer groups out of the box.
Let me know how this can be created.
Thanks in advance!
For history, I just recently wrote this question:
This has led to a follow up question. In the User Profile, "Roles" Tab (which I'm assuming is a table somewhere), is there a table I can report on that will get me what was changed and possibly by which user account (and maybe even the IP address of the user account)?
The path is:
Main Menu->PeopleTools->Security->User Profiles (and then the 'Roles' Tab).
Ultimately I need to figure out what change was made (when a role name was added) and by what user account and as of what date/time. If possible I need to link it to the IP address (which I think is found here: PSACCESSLOG).
what you need is audit on the PSROLEUSER table: you need to build an audit table for it and fill it either by a database trigger or through a PeopleSoft development: adding record audit to the PSROLEUSER table.
The PSROLEUSER table stores the roles a user is assigned. By default there is no history. To get that you would need to enable auditing, either record auditing through App Designer or setting up database trigger auditing. The database trigger audits can actually capture changes made either online or through the database so could be considered more complete, but can take some effort to get working properly. However, the database triggers also allow capturing some additional user information at the time of the transaction.
See http://peoplesoft.wikidot.com/auditing-user-profiles, particularly the section on using the the GET_PS_OPRID functions for Oracle or the SQL Server equivalent. Capturing the OSUSER and IP here would more reliable than trying to tie back to PSACCESSLOG.
I'm setting up SQL access in a newly created OpenEdge 11.5 database.
In checking the contents of the sysdbauth table using "select * from sysprogress.sysdbauth", I see that there are two users setup by default: sysprogress and a user with the name of the Linux user account that was used to create the database.
I'm looking for recommendations as to how to handle these two accounts. Obviously I want to have an account to use for DBA tasks. Should I use one of these accounts for the purpose? If so, what should I do with the other account?
Is it possible (and safe) to be deleting either of these predefined accounts?
On page 175 of the Database Administration guide you can read about default users and why they are created:
Tables used from SQL only
An SQL database administrator (DBA) is a person assigned a sysdbauth record in the database.
SQL DBAs have access to all meta data and data in the database. To support internal schema
caching, every OpenEdge database begins with a DBA defined as "sysprogress." However,
OpenEdge restricts the use of "sysprogress."
When you create an OpenEdge database using the PROCOPY or PRODB commands, and the
database does not have any _User records defined (from the source database, for example), then
a DBA is automatically designated with the login ID of the person who creates the database. This
person can log into the database and use the GRANT statement to designate additional SQL DBAs,
and use the CREATE USER and DROP USER statements to add and delete user IDs.When creating
users, this DBA can also specify users as SQL-only users, who can only access the database
through SQL.
There are several knowledge base entries around the task of deleting or disabling the default users.
http://knowledgebase.progress.com/articles/Article/P5094
http://knowledgebase.progress.com/articles/Article/P161411
This suggests that it's really safe to delete or disable these accounts but you should:
1) Create replacing accounts first.
2) As always: test in a separate environment first and not in production!
Yes, in fact Progress kind of expects you to do so. Create a root account and get rid of both. It's fine.
I'm constructing a website.
In this website, people will be able to manipulate several DB tables data.
Everytime someone wants to make a CUD operation I want to log it (like and audit).
The way I see it, I should use triggers for CUD operations, but I can't understand how do I log the user, since triggers don't accept any input parameter.
NOTE: the user I want to log is the network user. I know this user when they access the website (user to log <> user logged to DB).
ANOTHER NOTE: None of my tables saves creation date, creator, update date and updator. Just don't know why they should when I have the audit tables.
So this is the basic problem with web apps. If you have a huge user base ( more then say 500 ), then provisioning them in the database, while this is very easily doable, it is something most web programmers, sadly, don't want to deal with and want only ONE connection user for the database. You have already shot yourself in the foot because you don't have the created_by,modified_by, created_date, modified_date in the tables. To fix this you really only have one choice:
Put the columns on the tables and force the UI people to push the "network" user name through. The rest of the columns can be handled by one very simple trigger.
Why DB audit will not help you:
The DB audit feature ONLY deals with users defined as actual users in the database, sorry that is just the way it is.
Here are some things to look at when dealing with a front end system.
You can write SP's or Packages that execute as the schema owner, but can be run by ANYONE who is defined in the database and those can handle all the INSERT, UPDATE, DELETE operations on the schema they are defined in by simply giving other users the EXECUTE privilege on that set of SP's. This give the DB fine grain control over how tables are manipulated and you only have to grans the select privilege to all the users.
You can write a SP or Package in the SYSTEM schema that allows a group of people to provision users on the system by granting the execute privilege on that SP. Within that SP you define what ROLES they are assigned and therefor can control all their access.
In the process of creating the postgresql database "map" which uses the postgis extension, via CREATE EXTENSION postgis;, user "mapmaker" gets the following error:
permission denied to create extension "postgis"
HINT: Must be superuser to create this extension.
But user "mapmaker" is the database owner as specified by sudo -u postgres psql via the command:
CREATE DATABASE map OWNER mapmaker;
GRANT ALL PRIVILEGES ON DATABASE map TO mapmaker;
Once mapmaker is a superuser at the user level I no longer receive the error and the extension is created so I understand all I have to do is adjust the permission of mapmaker via the postgres user to superuser but I am interested in knowing why this is the case if the mapmaker was granted all privileges on the database map? Are extensions treated differently? In order to use extensions does a user have to be a user level superuser or can the permissions be allocated on a database level?
I did see cannot create extension without superuser role but the answer to the question did not explain why and, unfortunately, I do not have enough points to comment, hence the question.
PostgreSQL 9.1.9 PostGIS 2.0.3
In Packaging Related Objects into an Extension, the doc tells that an extension has a superuser parameter that, when set to true, indicates that only a superuser may install or upgrade the extension.
So that's the case of PostGIS, presumably because being implemented in the C language, there's no limit to what it can do to the entire cluster and data directory, not just one database. The superuser has authority over the entire cluster, which the owner of a single database does not have.
Just as the superuser privilege is required to create an individual function in the C language, it makes sense that the same rule would apply to the entire postgis extension for the same reason.