When using CDH 6.3.x-Hue by Sentry to control the access privilege of my impala datas, I find that the hue username must be a Linux username！
It's not elegant，So what shall I do to avoid to create username of Linux？ Use Hue by its username directly？
When you use Kerberos, there is no other way as it would defeat the purpose of security.
https://docs.gethue.com/administrator/configuration/server/#authentication
I only use Sentry with Hue to control the access of kudu,used impala query;
At last ,I found that Hue user must be created，and only Impala Coordinator Server is needed to do the thing--to create a same user of Hue on the server at the first!
Related
I am trying to provide DBAdmin privilege for a user on multiple databases.
I know how to do from on premises SQL database, I can directly map the user to required databases.
Can anyone let me know how to do it in Azure managed instance. Since the added user is external user, can,t see it in the Logins to map the user.
I have like 100 databases on which the user should have db admin right. Is there a easiest way to do that?
You can use an Azure Active Directory Login
eg
CREATE LOGIN [someuser#somecompany.onmicrosoft.com] FROM EXTERNAL PROVIDER
then create users mapped to this login in the appropriate databases, or make this login a sysadmin. Not sure if this shows up in SSMS, as it was added relatively recently. So you may have to create the users and grant them permissions in the target databases in TSQL, as per: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-aad-security-tutorial
I'm new to Hortonworks HDP; I have the following questions:
There are some users that if I don't create them, then even admin can't perform. For example, unless I create a user called hdfs in ambari, I won't be able to do a lot of the file/folder operations on HDFS. Should I create such users? Is this how others manage the cluster?
In Hive interface, I have to click on the 'Execute' button each time I want the query to be executed. Is there a keyboard shortcut for execute? For example in Oracle SQL developer, you press Ctrl+Enter to execute the query. That's what I'm looking for.
Ambari creates required users automatically. But you can set up LDAP if you have such need.
Ranger is also available in hortonworks, Using the Apache Ranger console, security can easily manage using policies for access to files, folders, databases, tables, or column. These policies can be set for individual users or groups and then enforced consistently across HDP stack.
I am new to Hive.
Can we create a group inside Hive and ensure that only group with functional id / password is able to access the archived data?
Thanks in Advance...
Privileges in HIVE can be handled using users, groups and roles. HIVE Language Manual has the details of the syntax and usage.
Also, if you are looking for further fine-grained security, you can make use of Apache Sentry.
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 to run a simulation with several postgresql databases spread on different machines which all of them are running linux.
I successfully compiled and built postgresql from the source code and I can also run the server, but when I try to create a new db with this command:
./postgresql/bin/createdb db1
I get this error:
createdb: could not connect to database postgres: FATAL: role "giulio" does not exist
where giulio is my username to access all the machines.
On some machine it works while on other it does not. I really cannot figure out the root of the problem. I suppose it is something related with the access control of postgres.
I did several research on google but I was not able to found and to solve the problem.
Does anyone know how to get this work?
Thanks,
-Giulio
PostgreSQL has its own users and roles that are separate from that of your OS. Generally there is a dedicated super user, postgres. For user management info, look here:
http://www.postgresql.org/docs/9.1/interactive/user-manag.html
When executing postgres commands, you need to specify the user with the -U flag (unless you are already logged in as an existing db user). When you called the createdb script, because you didn't use the -U flag, the server assumed that the uid of the caller (giulo) should be used, but you didn't add a user "giulio" to the db, and hence the error message.
So execute the command as
./postgresql/bin/createdb -U postgres db1
and it should work. Then, later on, you may want to create other users and roles in your db rather than doing everything as the superuser.
I would assume that on the machines where the user "giulio" is already known, you executed initdb with exactly this user making him the DB superuser. A quote from inidb(1) (emphasis mine):
--username=username
Selects the user name of the database superuser. This defaults
to the name of the effective user running initdb. It is really
not important what the superuser's name is, but one might choose
to keep the customary name postgres, even if the operating sys‐
tem user's name is different.
On the other machines I assume you did execute initdb with another user, hopefully using postgres.
In order to get back on the standard track I propose, that you delete the database cluster on the machines where "giulio" is the superuser and setup a new database cluster using the standard postgres user. Then add another user "giulio". This will avoid more confusion down the road as some scripts/programs expect a superuser account named postgres.
My answer was more simple...I realized I needed to just run the following:
brew install postgresql
then to check if it worked I ran:
which createdb
to check the file path and if it worked, and it had ! Hope this helps.