SHITTY Hosting? or just a different?
 

I need some feedback on some hosting issues.

Hypotheticals:

1. You run a cgi script on your site that creates a file that is chmod 666 but you can't delete it or even downoad it when logged in thru FTP. Shit or just different?

2. should I try to fix this in the script by doing dangerous stuff like running the script as setgid? (which I ain't gonna do, no matter what you say :1orglaugh)


I got cheap cheap cheap mainstream host to run scripts on to try and find all issues that people might have on their servers and I could not get even one of the problems that people are having on adult hosting.

Well, I was trying to hold out for a few more days to put the final touches on the new release but since you asked.

This is going into the new release:

http://facefux.com/channel.shtml/home

That template will come in at least 20 different color schemes.
No more messing around with templates unless you just want to!!

Here are other sites using the original templates:

http://tvfux.com
http://blackmonsters.com
http://crazypussy.com

Here are some sites that the webmasters made his own templates

http://tushytube.com/
http://pureporntube.com/

FUCk sorry for taking so long to reply but I clicked on this shit and got lost for a minute http://pureporntube.com/maintv.shtml/BBB_9431 :1orglaugh:1orglaugh

This is actually the same on all web hosts. By default the web server runs as user "nobody" with as few privileges as possible. Unix is strict on permissions so when you login to FTP as "myUsername" you can not modify anyone else's files except your own.

There are a few work arounds. If you're using CGI then you can configure suexec which allows individual VirtualHosts to execute as "myUsername" or any other user that you configure it for.

Another is to change the umask settings for Apache or your script, thereby allowing group read/write on new files and making sure that you're part of nobody's group.

Another is login to the server with root to do file management although this is quite dangerous, yet will allow you to make any changes you want without any server modifications.

You might check the permissions on the directory where you file is created; it's probably set sticky and/or immutable. Otherwise, make your own temp directory and set your files 666.

Then again, as a programmer, you're both aware, and knowledgeable of this.

Those are facts that I already know.

The question was "is it shitty hosting to not work around it and have the virtual account user trying to figure it out".

That depends if your definition of security is 'shitty', or not.

Generally people wanting to run their own software that's any larger than a basic CMS have at least one problem with their business plan.

BTW, I think that is what the host should be doing.

I don't think the webmasters should run scripts as setgid etc...

There's been a way to run securely (albiet much slower) since Apache 1.2, which was released in 1996. It's called SuExec. It allows you to set a UID/GID for every virtualhost. Providers often can't afford to run it due to programmers writing bad code, such as those assuming it's the job of the webserver to ensure files are accessable.

So you suggest that webmasters run their scripts much slower instead of you doing your fucking job. :1orglaugh

I believe in tight security but not locking myself in with iron bars so that I burn to death if there's a fire.

I don't want security so tight between each room that I have to use an axe to quickly hack into the bathroom if I feel a really wet beer fart comming.


RE: larger than a CMS:
The same issue applies to a simple message board script. The script has to delete the files it creates or wack the file with something like chmod 4777 so the user can delete thru FTP on those type configurations.
I don't think either of those conditions are highly desired.

You can have more lax security on your own servers. When it's a Virtualhost running probably 200+ accounts, you have to be careful. They're trying to protect themselves, and their clients. Faulting them for letting you create a file you can't read really isn't their problem.

That's why everyone on shared accounts constantly get their pages defaced - usually due to some old unpatched WordPress bug, linkex, etc.

The script should be able to delete it's own files, but the script should also chmod the files, or set the umask itself when creating them. If you don't set the umask in FTP (which is usually 022 for files), obviously, you'll need to alter that with your FTP client, since there's no concept of octal permissions on Windows.

If your FTP account isn't the same user and group as the webserver, you create a 'cleanup' script, which someone runs from their browser, which will unlink the files and send out a 'cleaned up' or 'file removal failed' message. It's trivial, at best.

OK, so chmod 0666 isn't good enough. What would you use?

Remember, we are talking about files that were chmod 0666.

Did you check if the directory was set immutable? Were there sticky flags? What were the permissions? What was the ownership of the directory? If the directory is 711, and you are not the owner, you can execute files in it, but not even read from it.

Both the directory and the files were created by the script as chmod 0777 for directory and chmod 0666 for the files.

Ok, maybe the domain directory in 711 and inherited.
But that would be an admin issue for most people.

Believe me, this is not a problem on all linux/unix servers because the admin has set the "real users" with permissions to delete and download from
user "nobody" or "nobody" automatically turns over ownership to real user.
I don't really know how they do it, but they do.

It's probably the differences between the user, and the user of the webserver, then. If you created the directory via FTP, and the script was writing files there before the directory was set 777, it will have problems writing files, there.

I agree that the domain directory should not be 711, it should be 755, but owned by the user; which still means that by default, the webserver (if not running as the user) will not be able to write there. Again, this is a security precaution to keep others on the virtualhost from messing with your shit.

Most larger virtualhosts use an SQL database as the back end for authentication and transparently set the uid/gid of the files when you upload them; they also have, or use SuExec policies so files will run as your user, with your user permissions. It's possible to even do this with CPanel, but nobody turns it on, since it's a performance hit as all PHP scripts now run as a CGI, rather than a builtin, and ho boy, do people bitch about tightened security.

Well, I just want a way around it for people on those type servers without setting uncommon file permissions. I could make directories chmod 4777 and that would solve the problem, but I'd rather stick to things that people beter understand. Everybody understands chmod 0777. And some servers might actually flag chmod 4777 and plenty of servers will not let a perl script run as setgid.

Any suggestions?

Wait till you try out the new release. It blows the current script away!

I think I should be able to release it this comming wednesday.

BTW: All updates and new versions are free for this script for life, so get
it while it's still cheap. :winkwink:

Your script will have to test/set the umask, then change the settings, accordingly. Herein lies the problem: If your FTP user is not your Apache/Web 'running as' user, you can't do it through a browser.

So, since you're using Perl, I'd look into Net::FTP, and create a form where they re-enter their FTP username, password, and all of that, and it logs in, and issues SITE CHMOD commands for them.

Sounds like too much work. I'm already working enough as it is.
My solution is for everybody to use phatservers or isprime :1orglaugh

I mean, there are several ways around it that involve me writing a bunch of new code. I'm just at the point that this stuff takes away from developing the part that makes money for people.

Heard at a Santa Monice workshop:

"There is no money in chmod". :1orglaugh