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.
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.
I have a requirement to validate if a given user can login to a machine. I don't know their password, but the script can elevate to root using sudo. All the users are AD accounts using SSSD.
Everything I've found just validates if the user is valid or not, such as using
id -u. Doing sudo -lu doesn't work if the user has never logged in before and only shows their sudo permissions. I've also tried using ldapsearch, but that only queries the AD server to see if they have the correct profiles, but not necessarily on that server.
Create in the Domain a group with the users you want to allow in the machine and use it in the key simple_allow_groups explained below.
In the /etc/sssd/sssd.conf Add/Modify the following keys:
access_provider = simple # This will allow you to control who can log in the computer using the simple_allow_groups.
simple_allow_groups = groupname1, groupname2 # Domain groupnames allow you to limit the log on permission for just the members of the groups in this option.
Edit the sudoers (using visudo) and add:
%groupname1 ALL=(ALL) NOPASSWD: ALL
This will allow the user to run any command. If you want to limit the commands allowed, see the examples in the sudoers file.
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}.
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 have an application using Oracle 9i as the database and I would like to grant update/delete/insert etc.. rights to only the session/connection used by this application.
I would like all other connections through excel, access, etc.. to be in a read-only state so it prevents the users from "accidentally" changing the data through these applications.
If I have all users start out with read-only rights then when they connect to this application, I would like to either call a specific stored procedure that would grant the user the proper rights only for that session though. Once they disconnect, the user would be back to read-only rights.
I have seen in other posts that you can add a trigger to the login so you can check if the connection is from application1.exe then you can do things or if they connect from 'excel.exe' you can stop them.
This is close to what I need to do but not quite.
My long worded question is "Can I grant rights to only a session/connection which would then allow that user the ability to update data based on a specific application running?"
Thank you for your patience in reading through this question.
Karl
create user A and grant him permissions to execute DML operations
create user B and grant only read permissions
Use user A inside your application
Use user B in Excel, access, etc