Chefry,

I pm'ed you my response since it included the benefit of an ongoing experience I have been having and was fairly lengthy.

xoops-end-user.com - BlueStocking profile

If you decide to go to my profile above then put 'hypermart' in the search bar on the *right ^Left^ hand side of the page and you may follow the calendar entries that record the invasion events and their eventual solution.

__________
*EDIT CORRECTION: pointed out by JAVesey, on next post. Delete right and insert left.

Quote:

There is no searchbar on the right-hand side of that pagelink. Putting 'hypermart' into the searchbox near bottom left doesn't help much.

There's also nothing to suggest that Chefry's problems are down to an invasion attempt. Nothing to do with tucows either.

Chefry - the other chaps posts are helpful; follow those.

While my host did not know why my entire database disappeared, they did restore it. But when they restored it, the size of my account spiked to more than double it's previous size.

After a lengthy discussion tonight we narrowed it down to a script error in either XOOPS or smartsection. I was busy posting all these articles but they were being attributed to 'nobody'. When they restored the backup they also assigned all the 'nobody' files to me.

That is the true size of my site. When they were being attributed to 'nobody' they were not included in my count.

Now they have set up a daily cron job to assign the 'nobody' items to me.

In the mean time, I had to delete an entire section of my site in order to get back under my size limit. They were nice enough to give me a separate backup file of that.

And they also set up a cron job to do a daily backup of the entire site, email it to a gmail account, then delete it from my account so it didn't eat all my space.

This is definitely a bug in either XOOPS or smartsection and everyone should start looking into just how many 'nobody' files they have on their sites.

Oh, and by the way, although I lost a lot of work i had done, it was creating new categories and duplicating files, so all in all I only lost about 50 recipes. I was also able to download the original html files form the server, so I'm sorting through them and reposting what I lost. So, I really only lost 2 days of work and no articles.

Hello chefry,

Can you maybe also post what probably happened concerning 'nobody' etc. in the forum of SmartFactory?

Just as info for the SmartSection developpers so they can have a closer look at the cause of the problem.

Thanks,

McDonald

I will, but quite frankly they don't really give a #OOPS#ed. It's pretty tough to get any kind of support form those guys :(

i'd have thought it more a server config issue than a XOOPS bug or smartsection bug. when a script writes as 'nobody', it's because the server config is configured in a way that makes it do that. it's to do with apache config if i'm not mistaken.

If you FTP a file to your webspace, the file ownership status will most likely be:

Owner: user
Group: user
Perms: 644

However, files created directly by the Apache web server by running a PHP script like XOOPS are typically given the status:

Owner: nobody
Group: nobody
Perms: 644

or:

Owner: apache
Group: apache
Perms: 644

This is quite normal. If you check the 'templates_c' or 'cache' folders you'll see lots of files owned by nobody, or apache. Any files uploaded via a module or the image manager will also be owned by nobody (unless your host runs SuEXEC or suPHP).

Provided the default permissions for such files is 644 (read permission for group and world) there shouldn't be any problems. If the permissions are different you may have a problem, but this is not a bug in XOOPS or SmartSection, it's just down to the way your web server is configured.

FYI: Chefry...
hypermart knowledgebase link

Note: The following package-
related files are protected and
not viewable through FileManager: .
scheduled_jobs, .ftpaccess, .quota, .membership and .trellix_data.
______________________
The ones in red were the entry point to xoops-end-user.com break-in. (not php programing but direct access through their root by a hypermart server ~ab~user)
______________________
Received: Tuesday, November 13, 2007 8:46 AM
From Giba regarding what could be of interest to you Chefry.

Subject: Important tips

Original link: http://www.cablan.net/phpsuexec.html

The security hole of PHP
On most Apache servers, PHP runs as an Apache module. As such, it runs directly in the user nobody, but doesn't require the execute flag.

This means that in order to execute a PHP file, it simply needs to be world readable.

The problem is that this allows every other users on the server to read your PHP files !

Allowing other users to read your HTML files is not a problem, since they can be displayed in Internet Explorer. However, PHP files are not readable, they are parsed.

Many scripts use a PHP file to store a database username and password. This means that on another server every client could read your PHP files, retrieve your password and access your databases.

Here is hoping you have good results in the end.