The docs and local.ini comments say that CouchDB would hash the admin passwords on restart. However, I've restarted the db several times now and the passwords are still unhashed in plain text. What could be the reasons for that? I'm running the Bitnami CouchDB version if that makes any difference.
This might be because the local.ini is not owned by the CouchDB user.
If the local.ini is for example owned by root then the CouchDB process can't write to it because it lacks permission.
Please check who owns the file with ls -l /opt/local/etc/couchdb/local.ini
If the local.ini is not owned by the same owner than CouchDB try to change its owner with:
sudo chown -R couchdb:couchdb /opt/local/etc/couchdb/local.ini
After changing the user restart CouchDB.
Note
Your path to the local.ini or your CouchDB user might be different than in my answer and you might need to change this according to your configuration.
To find who owns your CouchDB process you can use ps -aux | grep couchdb
Bitnami Engineer here,
I just wanted to let you know that we released a new version of CouchDB (3.0.0-6) including the fix on ini-file so you shouldn't experience this issue anymore with this new version.
It could take some days to be published in all the marketplaces.
Thanks so much for reporting this issue!
Related
At Debian im trying to change specific directory ownership after every reboot. But in my case it doesnt work, because user always set as root at reboot time.
When i try this in terminal it works well (i think because myUser session created) but i need to change it at reboot time.
So far i refer this link but it fails for me : https://unix.stackexchange.com/questions/183183/using-chown-useruser-inside-bash-script
CURRENT_USER=$(who | awk 'NR==1{print $1}')
sudo chown -R $CURRENT_USER:$CURRENT_USER /myfile/foo
second way:
sudo chown -R ${USER:=$(/usr/bin/id -run)}:$USER /myfile/foo
i dont want to write like this :
sudo chown myUser:myUser /myfile/foo
Linux is a multiuser system. There can be more than one users logged in simultaneously or no one at all. Often there is no way to define something like a "default" user. There are however workarounds that you could use to find the "default" user if the machines are setup as typical single user company computers.
Take the user with UID 1000. If all the machines are setup so that the "default" user has UID 1000, you could just use this UID instead of the username in the chown command.
Look for the subdirectories of /home. Only standard (non-system) users have a home directory. On standard systems they are named with the username.
That beeing set: Your script will be highly dependent on the specific setup of the machines. Also there might be a less intrusive, less machine dependent and more secure solution to your problem. You could try to
leave root as owner of the directory but enable read and write permissions for other users.
set the sticky bit for the directory (just like /tmp).
make a new group that owns the directory and add the users to it.
The last option is actually used a lot. For example often web servers make their source directories owned by a group called www and users, that are allowed to read/write the data are added to that group. This also works well in real multiuser systems like servers or shared machines.
I plan to create a web interface to configure a part of my system, including some files owned by root. I will be a NodeJS server and I know that running it as root is not a good idea.
Any suggestions about how to perform that without performance and security issues?
Thank you.
I decided to create a specific script that will be owned by root with high restricted rights and allow a sudo on that script for a dedicated user without password so that could not log in (only root can do a su on it).
In the script i will perform wanted action (updte, upgrade, files copy, etc.)
Let's hope that scurity is good enought
On Linux, how can I give www-data more permissions/privileges when I am logged in as that user? whoami = www-data
A bit of background. I have performed an ethical hack on a web application, I have managed to upload a file by bypassing the extension type which allows me to open a remote shell through netcap. The issue is, the default user for netcap is www-data and I cannot change user or escalate as I do not know how.
Any help would be great!
You can use sudo -u <another-user> command to gain the privileges of another user.
It may be intentional or maybe not, but you're basiclly asking "How to hack". If this is in purpose of homework, please add the homework tag to your questions.
Since you're saying it's a pentest, I'll assume this.
The first thing to do is to see what file do you have access to, and what you can do with them, and then perform the basic task of a pentest like checking the versions of the used packages, softwares or framework and to see if they're any known exploit on them.
I have a user called ec2-user and by this user I am getting connected to my EC2 instance by the help of the pem file I am able to connect to the machine,
Now I have added this user to the sudoers list by this command:
echo 'ec2-user ALL=(ALL) ALL' >> /etc/sudoers
This command executed successfully but after that when ever I want to do sudo its asking for password, when there is no password on the ec2-user.
Now, I have some of the questions:
If this is the wrong way, why Linux allows it to complete the command?
If this is right, then how to give the password?
If this I did in wrong way, how can I come back to my normal situation?
Thanks all
If this is the wrong way, why Linux allows it to complete the command?
No point in blaming Linux, It assumes that you have password set for an user.
If this is right, then how to give the password?
No, you can't provide a pasword because there is no pasword
If this I did in wrong way, how can I come back to my normal
situation?
Only way out is to boot the machine in single user mode and undo your changes. Unfortunately, you cannot boot an EC2 instnace into single user mode. Check with Amazon support whether they can help you with that.
You are pretty have run out of options. Create a new instance and then copy over your data by attaching EBS volume of this instance.
I assume you are using Amazon Linux AMI. For this AMI, by default the only account that can log in remotely using SSH is ec2-user. Also by default, password authentication is disabled to prevent brute-force password attacks. You must provide your key pair to the instance at launch, as you have already done. Please note that ec2-user has sudo privileges by default. When you do sudo, you don't have to enter any password. When you changed the sudoers file manually, you kind of changed the setting to require the password for any sudo operation by user ec2-user. Sorry that I don't know a easy way to get back to normal. I would suggest launching a new AMI instance and terminating your old one.
Related to my question: "How can I configure Cassandra to create files with custom rights?". I'm trying to approach the problem from the OS level.
Given two different Linux users - cassandra and tomcat7 - can I give tomcat7 read access rights to all the files which have read access rights by cassandra? The files are only o+rw (so I can't play around with groups); Cassandra keeps creating new files all the time so setting the group permissions manually isn't an option.
You could try changing the default file permission of the cassandra user using umask, assuming the mask isn't hard coded into Cassandra. This would allow you to add tomcat7 to the default cassandra user group with read/write access.
Somewhere in the shell profile or other config file for cassandra there is likely to be a line referencing umask with a setting of 077 or 0077. Replacing the first 7 with a 0 will allow rw for the group on all new files created. It is likely to be in the shell profile as it has it's own user, but it is sometime part of an application configuration file. You will of course need to change the file permissions of existing files, but this should be trivial.
The man pages don't do a brilliant job at explaining the ins and outs of the umask, but there is a nice tutorial on Understanding umask settings on Nix Craft. However, to guard against link rot, googling "linux umask" chucks up a whole bunch of tutorials from everyman and his dog.
There are two ways to do this
1) alter the uid in the password file to be the same for cassandra and tomcat7. Add cassandra and tomcat7 to the same set of groups
To show this actually works
a) add a user, I used the command
sudo adduser likeme --shell /usr/bin/zsh
I added a different shell so it is immediately apparent that this entry is being used
b) alter the uid in the /etc/passwd file. I used this command and edited the file so that the uid for my normal login (jamie) is used as the uid for the new user.
sudo vipw
c) test the new user. Here is what happens
$ who am i
jamie pts/10 2013-11-06 19:04 (:0.0)
$ sudo su - likeme
%
Note the prompt has changed because a different shell is being used. However:
% id
uid=1000(jamie) gid=1000(jamie) groups=1000(jamie)
It still says I am me!!
This is because in a fundamental way the two users are the same. You might say that there are two usernames but only one user.
2) configure sudo to allow tomcat7 to become cassandra
tomcat7 ALL = (cassandra:cassandra) ALL
Assuming you are also interested about non-system users which are supposed to be allowed to act as the other user, I would just allow him to log on as the other user.
If you are reluctant to just give him the password of the other user, then you can allow him to log on via ssh (locally) and pre-shared keys. For this, generate a key (ssh-keygen), store it in ~cassandra/.ssh/ and put the public part also in ~tomcat7/.ssh/authorized_keys. User cassandra should then be able to just switch to the other user using ssh tomcat7#localhost.