I created a user account on Amazon Linux Instance with root user. I found that if I create a user account(Example: ec2-user) that account will not have execute and write permissions on Hadoop Files System, Hive, Pig and other tools which are installed on Amazon EMR. If I have to give them explicit permissions I have to create a group which has permissions equivalent to superuser(root) account and add users to that group. Is there any other way I can set up access for those accounts to HDFS, Hive and Pigs etc.
Also while logging in as user the Linux command prompt is not prompting to enter any password even though I gave password for the user account while creating it. Is there anything configuration changes I need to make in /etc/ssh/sshd_config file?
Your question is not that clear to me.
But, let me attempt with whatever I suppose I understood.
Hadoop when security is enabled needs to have security for each user. It seems your user needs a separate space for writes and executions i.e. a Home directory.
First login as 'hdfs' user in a terminal and then create a home directory for your user in HDFS. Please check if you have a directory called /user/{yourUser}. If, not create that. Then, make sure you make {yourUser} the owner of /user/{yourUser}.
Related
I have an EC2 instance, where the backend for my Mobile App is hosted.
My developer needs access to my server, in order to upload the new code and I guess test it also.
Now, I do not want to give him FTP details, so here is what I did:
Created a new Linux User
Created a new Key pair from the EC2 Console
Created a .ssh directory
Change the file permission to 700 (so only file owner can read/write/open the dir)
Created authorised_keys with the touch command in the .ssh directory
Changed the file permission to 600 (so only file owner can read/write the dir)
Retrieved the public key for the keypair
Add the public key in the authorised_keys
Now I can share the new generated PEM file with my Developer along with the username and my EC2 host IP address.
But I don't understand why not I can directly to this by creating an IAM User from the AWS Console and set his permission accordingly?
I am really confused because I first wanted to do it the IAM way but everyone suggested I go with Linux user - isn't it the same thing?
Also, I shall delete this user entirely once he is done with the work - right?
Furthermore, I don't understand something... after doing all this and setting up the new Linux user, I am able to connect to my server using the Linux Username and Unix Password only - without using the PEM file that I have created - how is that?
Also, technically that new Linux user can simply delete my main Linux user... I mean I can simply right-click on the User and press delete via Filezilla for e.g. How can I prevent this from happening? Even though that wouldn't matter, as he could also simply delete my entire backend?
I have the following on my server now:
Home Folder
Home Folder > appBackend
Home Folder > mainLinuxUser
Home Folder > newLinuxUser
And last but not least, why is everyone always saying to never share the Private PEM file with anyone.. at the end of the day, if I only allowed specific IP address to connect to my EC2, then I should never be worried about anything? Same as I have done for my MongoDB - only if I add the IP address, only then that person can connect and view my Database. So with all the previous developers, I had shared my DB Configuration, it won't matter since their IP is not in my Security Group anymore - am I right?
Sorry, I am new to all this and I am trying to get my head around it all. I appreciate any help!
Creating Linux user vs IAM user :
IAM Users are for users who can access AWS resources based on permissions you provide. That means if you create IAM user with full access to EC2 and provide the details to your developer, he/she can login to AWS and have full access to EC2. He/She can create,start/stop, reboot, terminate your EC2 servers etc.
IAM Users/Groups are created to restrict access to AWS resources such as EC2, S3, VPC etc. and not for OS which runs inside EC2.
Yes, delete the user and keys once the work is done.
For login to linux sever, you can use either username-password or username-key. Check your user settings if you have set login with password. Use "--disabled-password" or similar when creating new user. Refer it here : https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance/
Check if you new user has root or sudo access. If you have provided sudo or root access, new linux user can execute such actions.
Note that, it is a best practice to delete the default root user on EC2 once server is up and running. ec2-user or ubuntu. Reason being, if your pem key which you had used when creating EC2 is compromised, your server is compromised. These default root users are known to everyone unlike specific users you'll create. Hence better to delete them.
Also follow the least access principle and provide only the least required access to new user. This means, you should create user as per the need or activity and restrict access to only that activity. Eg, if your user needs to only copy the files to/from within specific folders, set your user with a group and assign permissions to required folders. Do not provide any sudo access to it.
Similarly, you can create an admin user with access to sudo, however, make sure this user is not shared to other developers.
On many varieties of Linux PostgreSQL runs under a separate user account, so you have to do:
sudo su - postgres
to get any work done. That's all well and good if you just want to type SQL in manually, but what if you have a migration written in a programming language (in my case, Node/Knex)?
Is the common practice to somehow make the code aware of the user situation (ie. write something equivalent to sudo su - postgres in to my code)?
Or, is it to run all of my code as the DB user (even though that would mean giving my DB user permissions on my non-DB user's home folder)?
Or, is it to make my normal user have Postgres access (in which case why does Linux even bother setting Postgres up on a separate user)?
Or, is there some other approach I'm missing?
P.S. I realize this is somewhat a systems administration question, but I posted here rather than super user because it's specifically about running programmer-written code (which just happens to alter a database).
You are conflating three separate user accounts.
First there is the OS account under which the postgresql daemon runs. As you say in most Linux distros this would be a separate user used only for this purpose, often named postgres. This is to prevent other users on the system from accessing the postgresql data files and other resources, and also to limit the damage that could be done by someone who hacked their way into the database.
Then there is the user account which the client program, such as psql or your migration tool might run under.
Finally there is the postgresql user account. Postgresql has it's own user account system to manage the permissions of users within the databases that it administrates, unconnected to the OS user account system.
The one are of overlap between the OS accounts and the postgresql database accounts is that the psql command line tool will connect to the database using a user name the same as the OS user running the tool if you do not specify a user on the command line. For example, if I connect with this:
psql mydatabase
then it will attempt to connect with the user harmic, my Linux user account, but if I use this:
psql -U postgres mydatabase
then it will connect with the user postgres, which is the default administrator account.
Another related aspect is the authentication method. Most likely, if you try the above command on your machine, you would get an error. This is due to the allowed authentication methods, which are configured in the file pg_hba.conf. This file configures allowed authentication methods that specific users can use when connecting to specific databases from specific hosts. The postgres user is normally only allowed to connect from within the same host, using ident as the authentication method, which means identify the user based on the OS user running the command.
This explains why you have been using sudo su - postgres to switch to the postgres user: most likely in your current configuration that is the only way to access this account.
OK, this probably all sounds rather complex. To simplify things, here are my recommendations for best practices in this area:
Do not mess with the OS account used to run the database backend. It is not needed and would weaken security.
Create a separate database account for administrating the application's database(s). Use this account rather than the postgres account for migration scripts and the like. The reason for this is that the postgres account has full permissions over all databases on the server, while you can grant your admin user only the permissions it needs, and only to the database(s) the application controls (not any other databases that might be there). See: CREATE USER SQL command.
Update the pg_hba.conf file to specify the authentication mode that will be used to authenticate this user. See Client Authentication in the manual. md5 with a suitably strong password might be a good choice.
Update your migration tool to use this new user. The user (and password if using passwords) would be supplied via the connection string or connection parameters supplied when connecting to the database. Likewise when connecting with psql specify the user name with the -U option.
Note that there is no need to use sudo su - or even to have an OS account with the same name as the admin user.
I am attempting to integrate a standalone product into an LDAP environment.
I have a RHEL 6.7 system that is configured for ldap authentication (via sss) that I need to programmatically add local users and groups to.
The input xml file has a list of users and groups with their group membership, login shell, user id and group id that should be used.
Now comes the problem, I have a Perl script that uses the XML file to configure the users and groups, it uses the getgrnam and getpwnam to query for users and groups then makes a system call to groupmod/groupadd and usermod/useradd if the user exists or not. I found that if LDAP has a group the same name as the group I am trying to create my script will see the group as existing and jump to the groupmod instead of groupadd. Then group binaries will only perform operations on local groups, and fail because the group doesn't exist locally. NSS is setup to check files then sss, which make sense why getgrnam returns the ldap group.
Is there a way to have getgrnam and getpwnam only query the local system without having to reconfigure nsswitch.conf and possibly stop/start SSSD when I run the script?
Is there another perl function I can use to query only local users/groups?
Short answer is no - the purpose of those function calls is to make the authentication mechanisms transparent. There's a variety of things you could be using, and no one wants to hand roll their own local files/ldap/yp/nis+/arbitrary PAM authentication mechanism.
If you're specifically interested in the contents of the local passwd and group files, I'd suggest the answer is - read those directly.
I am trying to come up with a best approach for creating a user called appuser in Ubuntu. The reason to create this user is:
1. This user will be used to install and start applications like Tomcat, MySQL etc.
2. Other users will login to system using their account. Then using su appuser, they should be able to login to this user and manage tomcat, mysql etc.
What is the best practice to create this user?
1)Give 755 permission to mysql and tomcat folder so any one can read and execute application but dont write or modify the data.
2)also provide grant permission to mysql DB for users.
OR
those having full permission to application of tomact or mysql other user(new users) also part of that group.
OR
you can use ACL (access control list) for the same.
I have a dedicated Linux web server with many user accounts on it. The user accounts are all located in /home/[userid] directories. I am able to create Perl scripts that run within each of my users’ accounts that can access files only within their own account, but now I need to create a script that can run “above” the users’ accounts and be able to access a file within any specified user’s account.
Currently, I have a script that uses Net::FTP to retrieve the needed file from each account so I can extract the necessary data from it, but of course, it’s slow to FTP into every account. Since the accounts are merely directories on the server, I’m looking for a way to run a Perl script in a way that it can access each account directory and simply open the required file and return the requested data for the specified account.
How can I accomplish this?
You should login as a user that has access to all the user directories (e.g. root). For security reasons, it might be safer to use sftp or some other encrypted connection.