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.
Related
When I use googlesheets4 in R, I use sheets_auth() in the console and it works fine. But when I try to run it in R markdown, and when I try to knit, I cannot seem to get the credentials. Can someone walk me through the process? I've gone to the vignettes for googlesheets4 but cannot seem to understand it.
This is working for me
gs4_auth(path = "xxxxxxxxxxxxxxxx.json")
It doesn't return anything, but after that I'm able to write data in my sheet with sheet_write()
To get the credentials in a json file you have to follow these steps:
From the Developers Console, in the target GCP Project, go to IAM & Admin > Service accounts.
Give it a decent name and description.
For example, the service account used to create the googledrive docs has name “googledrive-docs” and description “Used when generating
googledrive documentation”.
Service account permissions. Whether you need to do anything here depends on the API(s) you are targetting. You can also modify roles
later and iteratively sort this out.
For example, the service account used to create the googledrive docs does not have any explicit roles.
The service account used to test bigrquery has roles BigQuery Admin and Storage Admin.
Grant users access to this service account? So far, I have not done this, so feel free to do nothing here. Or if you know this is useful
to you, then by all means do so.
Do Create key and download as JSON. This file is what we mean when we talk about a “service account token” in the documentation of gargle
and packages that use gargle. gargle::credentials_service_account()
expects the path to this file.
Appreciate that this JSON file holds sensitive information. Treat it like a username & password combo! This file holds credentials that
potentially have a lot of power and that don’t expire.
Consider storing this file in such a way that it will be automatically discovered by the Application Default Credentials search
strategy. See credentials_app_default() for details.
You will notice the downloaded JSON file has an awful name, so sometimes I create a symlink that uses the service account’s name, to
make it easier to tell what this file is.
Remember to grant this service account the necessary permissions on any resources you plan to access, e.g., read or write permission on a
specific Google Sheet. The service account has no formal relationship
to you as a Google user and won’t automatically inherit permissions.
(copied from here https://gargle.r-lib.org/articles/get-api-credentials.html#service-account-token)
We have a database that we are connecting to via RODBC, the accounts have been given read only access on the database side, however if we log in via R we are able to read/write/execute. I have been using the read only command within the connection command as follows:
odbcConnect(dsn = "DSN",uid="un",pwd="pass",readOnly=T)
I've noticed that, while users cannot write to tables or write to new tables, they can create new tables. I would like to ensure that users are unable to modify the database to open this to a broader user group. Has anyone found a sure fire way to limit user access from the R side?
Per comments made by Gregor, the issue is not R side it is database side. The system that was being dealt with was performing security checks on a front end application rather than at the ODBC handshake. As such, R had no way of enforcing rules that were not enforced server side.
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.
Several applications need SU to be run. What are the Unix rules about when a user needs this privilege? Is it whenever we need to modify something outside our home?
This question arose from a more specific one - why do we need to be root to insert a kernel module with insmod ?
Insmod requires superuser privilege because inserting a kernel module modifies the operating system kernel. The module will be able to read and write any memory within the system, read or modify any file on disk, change permissions, ownership of any resources, etc.
And generally these are the sorts of the things that are protected by the superuser privilege: ability to bypass access controls on memory, files and other resources, and to perform various administrative tasks needed to operate the system (and that might render the system insecure or unusable if allowed to a malicious user).
In linux, it is possible to configure the system in such a way that there is not in fact a single superuser, but a series of granular capabilities that each can be granted to individual users (indeed this is how it is modeled in the kernel source code: one does not check whether the current UID is zero, one checks whether the current user has the "change-ownership" capability [CAP_CHOWN]). In the huge majority of deployed linux systems, the system is configured with a single all-or-nothing superuser privilege (i.e. whether the calling user has an effective user ID of 0).
The single superuser privilege (EUID == 0) was the traditional model used in Unix from the earliest days, though there have been a number of implementations that provided more granular privileges.
Modifying files outside your home directory is one use, although it is possible to own files in places other than one's home directory, and it is possible for other users to own files within your home directory.
I am using sqlite3 in a linux machine and I am getting the database without username and password. Can I set a username and password for the same?
No, sqlite3 databases are very lightweight systems. They need no server and all data is stored in one file. A username/password is not supported by the sqlite/sqlite3 package.
In order to achieve simplicity, SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth.
(sqlite, when to use)
However, since it's only a file you can encrypt the file with a password to protect your data.
SQLite doesn't have a concept of username/password. It's just a single file based database.
However, on Unix you can protect your database from other users on the same machine by setting the permissions of the database file itself.
e.g. Allow only owner access
chmod 700 /path/to/sqlitedb
If it's used in a simple web application then the web application will provide the control.
The prior answers are only partially true. You can have databases that require authentication but you'll have to compile SQLite separately from PHP.
See the SQLite User Authentication documentation for further information.
SQLite is mainly an embedded database engine, not intended to be used as a multi-user database server that would require usernames and passwords.
You can always encrypt the database file with some user-provided password/-phrase, I guess. But expecting an embedded DBMS to sport full-blown access control is too much.