Page 5 of 11 FirstFirst ... 2345678 ... LastLast
Results 101 to 125 of 254
  1. #101
    Join Date
    Apr 2006
    Posts
    99
    Please don't turn this into an argument! I find this information posted above by both of you very valuable and know that it's something I'd need to look into.

    @Matt: Please don't leave because of a few users. I believe that you have quite a bit of knowledge that you could share that would help out a lot of the users tremendously. The way you say things does make it sound like you think that you're always right, so that might be something to look at. Either way, I believe you're a valuable resource and believe that you should stay.

    As for th issue above. What Matt says makes a lot of sense. If all scripts run as nobody and those scripts have rights to change the user who runs the scripts files, what's preventing them from changing others users php files?

    Say we have 2 users with php scripts that can do things to certain files. Both users have files with permissions to allow the scripts to change those files. Obviously the files will have to have the permissions set right to allow the scripts to edit the files. So user one can edit his files and user two his with the scripts run as nobody. Now if user one were to take user twos scripts and run user twos scripts from his account, those scripts will still be able to modify user twos files. In this same way user one will be able to make a script to wipe out the content of user twos files, given that the files have the permissions set to be modifyable.
    The most effective way to host your site

  2. #102
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    Quote Originally Posted by mheaton
    I am sorry, but you are totally wrong. Its not even arguable. This is basic permissions stuff. If it runs as nobody then any and ALL content created by a script in the users directory is writable by any other nobody user. This is security 101. It CAN'T be secure.
    It's not "arguable" because you aren't even reading what I write, apparently out of sheer obstinacy. A script running as nobody will create files owned by nobody. I did not say otherwise. What I said was that most scripts do not need to create files. Therefore, the only files we're talking about are the ones uploaded by the customer, which are owned by the customer's account and therefore not overwritable!

    Not only are you pretty much ignoring what I'm saying, you're coming across as unbearably arrogant about it. I'm embarrassed for both of us.

    Quote Originally Posted by mheaton
    If each user was insulated from each other then mod_php wouldn't be able to write to the directory which is obviously not the case or none of your users scripts would work.
    I'll say it yet again. Most scripts do not need to write files in order to run.

    Quote Originally Posted by mheaton
    Ask any of the mod_php developers themselves and they will be the first to admit that it shouldn't be run in a shared environment for this exact security reason.
    Please, go find one.

    Kevin

  3. #103
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    Quote Originally Posted by bullfrog
    As for th issue above. What Matt says makes a lot of sense. If all scripts run as nobody and those scripts have rights to change the user who runs the scripts files, what's preventing them from changing others users php files?
    Why would a script running as nobody have the right to write to any files owned by a user account? It doesn't have those rights; the premise is false. The only way it would be able to write to files it doesn't own would be if the permissions are wrong (files 666, directories 777, for example), in which case any user account could do the same thing.

    Say we have 2 users with php scripts that can do things to certain files. Both users have files with permissions to allow the scripts to change those files. Obviously the files will have to have the permissions set right to allow the scripts to edit the files. So user one can edit his files and user two his with the scripts run as nobody. Now if user one were to take user twos scripts and run user twos scripts from his account, those scripts will still be able to modify user twos files. In this same way user one will be able to make a script to wipe out the content of user twos files, given that the files have the permissions set to be modifyable.
    Why on earth does everyone keep assuming that for a script to execute, it has to be overwritable itself or has to be able to overwrite other files? That's a completely separate issue.

    It's interesting that Mr. Heaton thinks someone compromising a "nobody" script and running "rm -rf" and perhaps deleting some temp files is worse than the same compromise in a 100% wrapped environment - in which case the same "rm -rf" just wiped out the user's account. Or a sophisticated attacker could just backdoor the user's account (via .login, for example). None of that is possible in the "nobody" account.

    Kevin

  4. #104

    Oh my...

    You still don't get it? The nobody user has FULL 100% WRITE ACCESS to all your user directories and all your users can run anything they want as nobody? Your assertions that scripts don't create files in home is looney, and dangerous for your users. So basically you would be saying that unless it was a MySQL write that nothing is ever written by a script?!?!?

    In other news, the world is confirmed to be flat afterall, up is now down, and down is now up, and gravity was just a fad and no longer affects us. Its true - user sigma told me so!
    Matt Heaton / President Bluehost.com - Hostmonster.com

  5. #105
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    Quote Originally Posted by mheaton
    You still don't get it? The nobody user has FULL 100% WRITE ACCESS to all your user directories and all your users can run anything they want as nobody? Your assertions that scripts don't create files in home is looney, and dangerous for your users. So basically you would be saying that unless it was a MySQL write that nothing is ever written by a script?!?!?

    In other news, the world is confirmed to be flat afterall, up is now down, and down is now up, and gravity was just a fad and no longer affects us. Its true - user sigma told me so!
    Matt,

    Why must you be so arrogant? Is civil discussion just not possible with you?

  6. #106
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    Quote Originally Posted by mheaton
    You still don't get it? The nobody user has FULL 100% WRITE ACCESS to all your user directories and all your users can run anything they want as nobody? Your assertions that scripts don't create files in home is looney, and dangerous for your users. So basically you would be saying that unless it was a MySQL write that nothing is ever written by a script?!?!?

    In other news, the world is confirmed to be flat afterall, up is now down, and down is now up, and gravity was just a fad and no longer affects us. Its true - user sigma told me so!
    Wow, you are really off your rails. That last paragraph is so classy.

    I will say it one more time - you are flat wrong. User nobody does not have write access to user-owned directories or files. A script owned by a user can run as user nobody without having any additional privileges.

    You see, a process running under one userid cannot overwrite files owned by another userid, unless the files are world-writable and therefore overwritable by anyone. This is fundamental UNIX - are you perhaps a DOS user? Do you actually use UNIX? Do you need an example to show the obvious? For example, a PHP script owned by my account, running as user nobody, that can't write to the directory it's running in because my account owns it. Simple as can be.

    And of course, many scripts have no need to write files. Scripts may very well just want to send output to the user, you know.

    I'm amazed that now your cluelessness seems to be struggling to outstrip your arrogance. And that's a tough battle.

    Kevin

  7. #107
    Join Date
    Mar 2005
    Location
    USA
    Posts
    667
    Guys, guys, let's not argue. Matt may have a different approach about him but give him time, he'll get used to us and hopefully we'll get used to him. Is he somewhat cocky and arrogant? To be honest, I really wouldn't expect anything different. He's not cocky and arrogant because he owns Bluehost and Hostmonster, he owns Bluehost and Hostmonster because he's cocky and arrogant. I'm not condoning it, I'm just saying many people are like this. He brings up some very interesting points and a different approach to things. I think if we can all get past each others views and occasional bs, Matt might become a very good addition to our little community. After all, that's what this forum is all about.
    Jim - 2Macs H-Sphere Web Hosting
    Since 2001 - H-Sphere Clustered Shared Linux & Windows Hosting
    Fully Managed Services| Custom Web Designs
    Unconditional, 30 Day Money back Guarantee!

  8. #108
    Join Date
    May 2002
    Location
    Internet / Colorado
    Posts
    1,660
    Quote Originally Posted by 2Macs Jim
    Guys, guys, let's not argue. Matt may have a different approach about him but give him time, he'll get used to us and hopefully we'll get used to him. Is he somewhat cocky and arrogant? To be honest, I really wouldn't expect anything different. He's not cocky and arrogant because he owns Bluehost and Hostmonster, he owns Bluehost and Hostmonster because he's cocky and arrogant. I'm not condoning it, I'm just saying many people are like this. He brings up some very interesting points and a different approach to things. I think if we can all get past each others views and occasional bs, Matt might become a very good addition to our little community. After all, that's what this forum is all about.
    Forums are also places where a little civility is needed, esp a business forum that prospective customers might read. This isn't a forum about religion or something people will call others names and scream at.... I could be wrong though from posts. Also arrogance and lack of humility are not prerequisites for running a successful business.

  9. #109
    Join Date
    May 2002
    Location
    Internet / Colorado
    Posts
    1,660
    Quote Originally Posted by 2Macs Jim
    Guys, guys, let's not argue. Matt may have a different approach about him but give him time, he'll get used to us and hopefully we'll get used to him. Is he somewhat cocky and arrogant? To be honest, I really wouldn't expect anything different. He's not cocky and arrogant because he owns Bluehost and Hostmonster, he owns Bluehost and Hostmonster because he's cocky and arrogant. I'm not condoning it, I'm just saying many people are like this. He brings up some very interesting points and a different approach to things. I think if we can all get past each others views and occasional bs, Matt might become a very good addition to our little community. After all, that's what this forum is all about.
    Forums are also places where a little civility is needed, esp a business forum that prospective customers might read. This isn't a forum about religion or something people will call others names and scream at.... I could be wrong though from posts. Also arrogance and lack of humility are not prerequisites for running a successful business.

  10. #110

    Ok...

    Quote Originally Posted by sigma
    Wow, you are really off your rails. That last paragraph is so classy.

    I will say it one more time - you are flat wrong. User nobody does not have write access to user-owned directories or files. A script owned by a user can run as user nobody without having any additional privileges.

    You see, a process running under one userid cannot overwrite files owned by another userid, unless the files are world-writable and therefore overwritable by anyone. This is fundamental UNIX - are you perhaps a DOS user? Do you actually use UNIX? Do you need an example to show the obvious? For example, a PHP script owned by my account, running as user nobody, that can't write to the directory it's running in because my account owns it. Simple as can be.

    And of course, many scripts have no need to write files. Scripts may very well just want to send output to the user, you know.

    I'm amazed that now your cluelessness seems to be struggling to outstrip your arrogance. And that's a tough battle.

    Kevin
    Tell you what? Give me an account on one of your servers for 72 hours. Nothing special, just give me access to mod_php like all your other users and put me on a server with other user accounts. I won't do anything destuctive but I will be able to not only list every "webable" file for every account on your server, but I will also "touch" (create a 0 byte file) a file in the directories of every single one of your users. I'll even give you all the source code for the breach so you can fix it on your end? If I am wrong then I am embarressed on the forum and will publicly admit to everyone where I made my mistake, otherwise just admit that ALL "nobody" created files or 777 files can be deleted at will by any user.

    I admit that I have been a little rude in my above posts. I apologize for that, but I certainly don't apologize for being right
    Matt Heaton / President Bluehost.com - Hostmonster.com

  11. #111
    <BEGIN ATTEMPT AT HUMOR>

    Quote Originally Posted by mheaton

    I admit that I have been a little rude .... I apologize for that, but I certainly don't apologize for being right
    I said this exact same line to my wife after an argument yesterday.

    </END ATTEMPT A HUMOR>

    In all seriousness, I have to admit that I do enjoy Matt's posts. He does make interesting points, regardless of whether I agree/disagree or think he's right/wrong.

    My point -- Matt I hope you stick around here and keep contributing. WHT is an "interesting" place, and having you around is valuable to the community. It's good to have differences of opinion and vibrant discussions.

    We are eNom PLATINUM PLUS resellers!
    Sign up today for an eNom.com reseller account with lowest possible pricing.
    * We provide support and service to over 4275 happy eNom domain name and SSL certificate resellers!

  12. #112
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    Quote Originally Posted by mheaton
    Tell you what? Give me an account on one of your servers for 72 hours. Nothing special, just give me access to mod_php like all your other users and put me on a server with other user accounts. I won't do anything destuctive but I will be able to not only list every "webable" file for every account on your server, but I will also "touch" (create a 0 byte file) a file in the directories of every single one of your users. I'll even give you all the source code for the breach so you can fix it on your end? If I am wrong then I am embarressed on the forum and will publicly admit to everyone where I made my mistake, otherwise just admit that ALL "nobody" created files or 777 files can be deleted at will by any user.
    $8.95/month gets you a regular account with SSH access; there's even a 30-day moneyback guarantee. You don't need any help from me to do that.

    I did not state that files created and owned by nobody could not be interfered with by other users. I also did not state that world-writable files could not be overwritten. You haven't been listening to what I'm saying. Your assertions have been far broader.

    User accounts are not world-writable (unless the user changes the permissions), nor are they writable by user nobody. So you won't be creating files in them unless you own the account. That's basic Unix permissions again.

    Getting listings of other users' files is similarly meaningless. It's Web content, there to be published through the Web. If the content needs protected, it can be wrapped.

    Kevin

    ps Apology accepted.

  13. #113
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    Quote Originally Posted by mrzippy
    My point -- Matt I hope you stick around here and keep contributing. WHT is an "interesting" place, and having you around is valuable to the community. It's good to have differences of opinion and vibrant discussions.
    I do enjoy the topics as well. I know Matt runs his servers a particular way and as I've already said, I respect that. But that's not a license to disrespect other ways of running servers, particularly by spreading misinformation.

    Kevin

  14. #114

    Huh???

    Quote Originally Posted by sigma
    User accounts are not world-writable (unless the user changes the permissions), nor are they writable by user nobody. So you won't be creating files in them unless you own the account. That's basic Unix permissions again.
    If a users scripts don't have write permissions in the persons home directory then scripting is basically useless. Either you have a massive security hole, or scripting on your
    servers is totally inept and worthless because you can't do anything (writing disabled on your servers). Mod_php means all php runs as a single user. You either support writes or you don't? You are saying you dont'?!?!? Huh?? What you are saying is that a user couldn't write a php program that saves the number "1" in a flat file (textfile) in their directory. Wow thats powerful scripting This will be my last message on the topic so you get the last word if you like. We are going in circles. I can bring a horse to water but I can't make em drink or in this case even take a sip. Good luck
    Matt Heaton / President Bluehost.com - Hostmonster.com

  15. #115
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    Congratulations, you're finally starting to listen and understand. You apparently have a very limited view of scripting if you think every script has to write some local file on the server. Scripts are very useful for many other purposes besides that (and they can use /tmp for session storage). Most scripts do not need to write local files in order to be useful.

    Of course, even if a user wanted to write local files as nobody in a writable directory, that doesn't mean their other files could be overwritten; you're taking an all-or-nothing view of the possibilities.

    Kevin

  16. #116
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    mheaton,

    PM me and I will set you up an account on one of our servers. Then you let us know if you can "touch" your file.

  17. #117
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    Here we go...I'll even test it myself.

    Source code: http://www.accelerated.be/write.phps

    http://www.accelerated.be/write.php

    There you go, can't even see the file, period, due to open_basedir, and even when you remove open_basedir you cannot write to the file;

    Warning: fopen(/home/geek/public_html/file.txt) [function.fopen]: failed to open stream: Permission denied in /home/admin/domains/<<>>/public_html/write.php on line 3
    can't open file
    That's the error you get, without open_basedir.

    Our PHP setup:

    PHP 4.4.x running as mod_php4, [open_basedir enabled]
    Zend Optimizer, Suhosin, and eAccelerator.

    No offense, but not only is running PHP as CGI significantly slower than mod_php, but you also cannot run eAccelerator or any other such optimizer (and cache). Therefore, there is no way, even with FastCGI, that your servers can come close to the level of performance in a properly tuned mod_php setup such as ours.

    Best,

    P.S. Can't wait to see your "public apology"
    Last edited by layer0; 04-01-2007 at 03:56 PM.

  18. #118

    Wrong again...

    Jeeze, I hate being right all the time You CAN run Eaccelerator/Xcache or other php accelerators that save compiled opcode in memory with Fastcgi and CGI mode. Its hard to do and we did submit the patch back to the Fastcgi community so they could include it in the next release if they choose. I know you can do this because we have it running now on several of our servers. Again, it seems that everyone has a preconceived idea of what is possible. I do admit that this was VERY difficult to accomplish and took our best developer almost 2 weeks to make work. It does have the disadvantage of not being able to share memory in a normal mod_php/perl setup, but the speed is the same and the security is MUCH better. This is on several servers on Bluehost and in a few weeks will roll out to Hostmonster. We have taken Eaccelerator and Xcache a step further by writing our own dynamic cache to go along with it that will handle get/post/ip/cookies etc to cache output of a dynamic script. This doesn't work well for all scripts, but certain ones like wordpress, gallery, etc where the mainpage doesn't change all the much is orders of magnitude faster. My mattheaton.com site could handle more than 300x the traffic to it in our tests because instead of hitting php and mysql on every hit it simply displayed the cached static HTML page generated by the output. We will allow you the set the cache time from 30 seconds to 60 minutes. For sites that get slashdotted or tons of traffic from digg it won't cause our servers to be hit anywhere near as hard. The best part is because it is something we wrote ourselves it is tightly integrated and requires NO modification of any scripts to work. You will simply enable PHP Acceleration as the first step, and then choose to turn on Dynamic Caching (If you want it). We also track #hits per second and real time cpu usage so we can turn this on for accounts that are killing the system if it happens and then off when the server calms down without having to have personnel intervene for every instance.

    What I am saying is that you shouldn't always take everything at face value. The information out there says you can't do this with CGI and Fastcgi. I never take "No" for an answer and so we just fixed it to work. The same goes for your disbelief that mod_php is insecure. Blah, I really am beating a dead horse now and you got me to post again You are good!
    Matt Heaton / President Bluehost.com - Hostmonster.com

  19. #119
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,710
    Quote Originally Posted by mheaton
    Jeeze, I hate being right all the time You CAN run Eaccelerator/Xcache or other php accelerators that save compiled opcode in memory with Fastcgi and CGI mode. Its hard to do and we did submit the patch back to the Fastcgi community so they could include it in the next release if they choose. I know you can do this because we have it running now on several of our servers. Again, it seems that everyone has a preconceived idea of what is possible. I do admit that this was VERY difficult to accomplish and took our best developer almost 2 weeks to make work. It does have the disadvantage of not being able to share memory in a normal mod_php/perl setup, but the speed is the same and the security is MUCH better. This is on several servers on Bluehost and in a few weeks will roll out to Hostmonster. We have taken Eaccelerator and Xcache a step further by writing our own dynamic cache to go along with it that will handle get/post/ip/cookies etc to cache output of a dynamic script. This doesn't work well for all scripts, but certain ones like wordpress, gallery, etc where the mainpage doesn't change all the much is orders of magnitude faster. My mattheaton.com site could handle more than 300x the traffic to it in our tests because instead of hitting php and mysql on every hit it simply displayed the cached static HTML page generated by the output. We will allow you the set the cache time from 30 seconds to 60 minutes. For sites that get slashdotted or tons of traffic from digg it won't cause our servers to be hit anywhere near as hard. The best part is because it is something we wrote ourselves it is tightly integrated and requires NO modification of any scripts to work. You will simply enable PHP Acceleration as the first step, and then choose to turn on Dynamic Caching (If you want it). We also track #hits per second and real time cpu usage so we can turn this on for accounts that are killing the system if it happens and then off when the server calms down without having to have personnel intervene for every instance.

    What I am saying is that you shouldn't always take everything at face value. The information out there says you can't do this with CGI and Fastcgi. I never take "No" for an answer and so we just fixed it to work. The same goes for your disbelief that mod_php is insecure. Blah, I really am beating a dead horse now and you got me to post again You are good!
    Whatever. I don't care about that issue. We didn't have to hack anything to get our setup working. But, good to hear that you've got it working nonetheless.

    Granted, you have yet to comment on the information in my post above, showing you that you were 100% incorrect in most of your previous posts in this thread? Care to comment on that? Where's that public apology you promised, huh?

    Oh, and...

    Jeeze, I hate being right all the time
    You sir are by far the most arrogant person I have ever seen on WHT.
    Last edited by layer0; 04-01-2007 at 10:23 PM.

  20. #120
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    He hasn't had anything to say about the danger to a user's account when wrapped scripts get compromised, either. There seems to be a huge willful blind spot to his own errors and misconceptions, while he is simultaneously asserting "it seems that everyone has a preconceived idea of what is possible".

    He is a fascinating character, to say the least.

    Kevin

  21. #121

    Wrapped scripts

    Yes, I don't disagree that wrapped scripts withing FastCGI have a potential for problem if FastCGI is compromised. Normal CGI doesn't have this issue as it run all the time as their own user. I just happen to believe that a single process that changes to an individual user all the time is 10x better than running EVERYONE as nobody and hoping the crappy open basedir jails the users from each other. That is like putting a matchstick in front of a semi and saying you can't get by me because I am blocking you.

    What is your hosting company URL so I can test out your service?
    Matt Heaton / President Bluehost.com - Hostmonster.com

  22. #122
    Join Date
    Feb 2002
    Location
    Australia
    Posts
    24,027
    Quote Originally Posted by mheaton
    . . . What is your hosting company URL so I can test out your service?
    Kevin runs Pair.com. Go easy on them, as they've only been in business since Moses played fullback for the arabs.
    WLVPN.com NetProtect owned White Label VPN provider
    Increase your hosting profits by adding VPN to your product line up

  23. #123
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    I don't recall saying anything about FastCGI at all. I said that scripts running as the user present a greater problem when they are compromised remotely. Scripts running as nobody have fewer privileges; it only took me five posts or so to get you to see that, remember?

    Kevin

  24. #124

    Oh My Gosh!!

    What?? "Nobody" has fewer privileges on OUR server, but not yours. You made "nobody" have privileges the second you decidedto run mod_php as Nobody. Now it has ALL the privileges. Thats the whole point. Now nobody has execute rights in your users home directories. On our servers "nobody" is really nobody and can't do anything and has no rights. Also, not sure why you said "remotely" is an issue? Its neither more or less secure remotely when talking about scripts!? If port 80 is open and I have a cgi-bin I can do anything with a script that you can do locally with shell access. It doesn't matter with scripts. We aren't talking about exploits on open ports through remote atttacks?!?!

    Scripts that run as their own user, if compromised, allow you to remove anything owned by that user. It will not and does not affect any other user. IE if PhpBB gets compromised for a single user on our server it doesn't affect any of our other users.

    Scripts that run as nobody where individual files are owned by someone else such as user "user1" are worthless in my opinion. Either you have to chmod your files that are owned by "user1" to a writable permission in (Example path only) - /home/user1/filename or you have to create "nobody" owned files in /home/user1/file or in /tmp (Which is silly by the way because many scripts required long term storage in a users directory and forcing a user to use /tmp is bad form at least and will make your customers hate you at worst).

    So you have 2 possibilities - 1) Files in a users home directory that are owned by BOTH the user AND nobody (Horrible HORRIBLE idea), OR you have scripts that simply can't write in their home directory and you tell them to use /tmp!?!? Pick your poison.
    Last edited by mheaton; 04-02-2007 at 12:31 AM.
    Matt Heaton / President Bluehost.com - Hostmonster.com

  25. #125
    Join Date
    Apr 2001
    Location
    Pittsburgh, PA
    Posts
    1,306
    False dichotomy. You're again ignoring other people's statements and creating your own versions of the topics at hand (e.g. that all scripts require writing to user directories). I'm not going to keep explaining file permissions and scripting to you.

    Best wishes, sir! Especially with the 200GB plans, which as I recall, were the original content of this thread.

    Kevin

Page 5 of 11 FirstFirst ... 2345678 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •