I think i did some nasty crap today...
I deleted the user (admin root) in phpmyadmin (XAMPP)
now I can't create new users.
Any idea how to fix, or should I just try re-install the hole XAMPP packet :-/
I use Leopard iMac.
/Willy
There is a method for resetting permissions in the MySQL manual. It deals with resetting the root password rather than recreating the root account, however I think you should be able to modify the method to re-insert the root account without any trouble.
Following the steps listed there (either method), if you change step 3 to insert a new account (fields might vary, this worked for my particular install):
INSERT INTO user VALUES('localhost','root',PASSWORD('some_pass'),'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
FLUSH PRIVILEGES;
You should be able to take it from there and get the permissions back up to snuff.
Related
I had a server that had a lot of users on it, its operating system was cloudlinux and had cpanel!
This server is used for Python projects and had bin/bash!!! access
Suddenly the command rm -rf * was typed on the server and all the data was deleted !!!
We quickly uploaded the backups and hacked the possibility and restricted ssh access to the root server!
But the next night we were hacked again, this time with the monitoring we had at whm! , we noticed that someone enters whm and quickly changes the password !!!
My question is whether users with access to bin/bash! can find the root password ???
We are now giving users access to JailShell in CPanel and full SSH access is closed. Do you have any idea how this happened?
Did you encounter a similar case?
Does bin/bash access allow the user to see the password?
Thank you for sharing your comments with us
It's difficult to obtain a Linux password, even with full access to the computer. That's because the passwords are stored in hashed form. Probably the only reliable way to get a password is to install a trick password change program, which does the change, but also sends the password somewhere else.
However, you don't need the password to get full access to a computer. There are several other ways in, and anyone who can access /bin/bash is likely to be able to test them and probably find one that works. Once they get full access, most intruders will install some other program that will let them in in the future, even if the original security hole is patched.
Once a machine is compromised, it's pretty important to burn it and start fresh. You can't trust it otherwise.
I faced problem for accessing webmail in cpanel. it say user x#x.com don't have authorize to access. after that when i go in WHM and use Repair Mailbox Permissions i see some ownership and permissions changed and everything become fine.
Now the problem is after some time it cause problem and show error message again.
Fixed ownership on /home/x/mail/x.com/support/dovecot-quota: was (501:505), now (501:502)
Fixed permissions on /home/x/mail/x.com/support/dovecot-quota: was (0600), now (0640)
any idea?
It's because your WHM version changes. if you recently do some changes is your WHM version (Updating), you see this kind of error may happen. So it may take some times to fixed.
In the other hand put your IP into cPHulk Brute Force Protection whitelist too.
A fresh installation, installed via an installer (Softaculous, to save time.)
Data seems to be correctly connected and all in the correct places. But most error messages only contain the word "undefined."
I have a feeling it's a permission problem, but the various solutions for it on forums are varied and only seem to work for a small section of people for each.
I'd rather not do a reinstall as all the old data from previous CRM is now imported.
This is running through a cPanel controlled server BTW, if that helps matters.
Yes, It's permission issues. Please update write permission for the web server user and try to delete " cache/jsLanguage/en_us.js " folder from your account.
If a Suite or Sugar install is installed on a temporary I.P whilst using cPanel, at least in our version of cPanel, it hosts the files in a temporary test folder.
Suite (specifically SugarBean.php) tries to access the folders that would exist on permanent domains. So it calls files that are hosted elsewhere on the server.
Soon as the site was pointed to a real domain, it fixed itself, no extra steps necessary, as the files were hosted in the correct place.
Thanks to the hosting company, they explained that to me. I'm not sure if that's standard procedure to store the files differently for temporary i.p addresses.
make sure you are using correct .htaccess
Go to Admin > Repair and do a "Quick Repair & Rebuild". Execute any changes shown at the bottom of the page.
If that doesn't work, go to Admin > Repair and do "Rebuild .htaccess file" and afterwards, Admin > Repair and do a "Quick Repair & Rebuild" again.
All members in the Administrators group can NOT access "All-Project".
I am afraid that the read permission is removed from "All-Project" for admin.
How can I recover it.
And I can find project.config in the ./All-Project .
If you can still ssh then you can checkout All-Projects.git and edit the config.
If you have access to server, you can even navigate to the All-Project.git directory (its a base repo) and rollback to an earlier change. (Obviously backup everything first if you're not very confident of what you're doing).
I am new to Joomla and have been given the task of supporting a site that was created in Joomla 1.5.25. They keep getting errors that files are not writable. They also can't add or delete anything to and from the media manager even in a Super Administrator account. I was able to override these errors with changing folder permissions from 755 (Joomla's recommended permission set) to 777, but was wondering if there is a better way of going about this (I don't want to leave a security hole on their site with the 777 permission set). From what I have read through my research is Joomla permissions requirements can vary based on your hosting company, so I want to get other peoples input before I give my hosting company a call.
On a side note, is there a way of getting the error messages to display longer then 2 seconds?
Why don't you try changing the permissions only to the folders that are written to temporarily? Another solution is to find out under which user apache is running and make sure that user is the owner or at least in a group that owns your Joomla! directory.