SMF Development > Fixed or Bogus Bugs

SMF 2.0 RC4 unable to download and install new packages [SOLVED]

<< < (2/4) > >>

holodoc:

--- Quote from: Oya on November 04, 2010, 06:29:40 PM ---but surely the systemwide temp folder is similarly locked down on most shared hosts, and where it's not, there's an implicit security risk from other users on the same host being able to get files in?

--- End quote ---

--- Quote from: Kindred on November 04, 2010, 08:53:58 PM ---if you are on a shared host, you can not get to the system temp folder, as Oya points out.

and, BTW: If a windows server has permissions correctly set, there could indeed be a problem with creating files or folders...

--- End quote ---
It seems to me that I was not clear enough in my previous post so I'll try to further clarify what I meant to say :)

When I first mentioned the /temp folder in my previous post I was not referring to any specific web server setup and layout which means that the term /temp folder was supposed to represent that what the web application and the end user see as the /temp folder :)

In other words both dedicated and shared hosting web servers will have access to the /temp folder however the important difference is that in case of a dedicated system web applications will access the real top-level /temp folder but in shared hosting environments web applications will actually access the chrooted (jailed) /temp folder :) Of course I don't have to emphasize that any shared hosting provider which doesn't enforce user chrooted accounts is not worth mentioning, right? :) Practically that means that the web application doesn't have to worry about where the actual /temp folder is just that its always accessed with the same path (/temp) and that it allows full access for the web application.

--- Quote from: Kindred on November 04, 2010, 08:53:58 PM ---and, BTW: If a windows server has permissions correctly set, there could indeed be a problem with creating files or folders...
--- End quote ---
Well whatever restrictions and policies you enforce on a Windows based web server a /temp (or /tmp) folder is usually always present and available to the end web applications to prevent compatibility issues with software that might require it (PHP etc). However the good thing about PHP and Windows based web servers is that these two things combined are usually not the weapon of choice for any web site or application ;)

Oya:
um... i think you're missing one little detail

when not using db sessions, php writes those as files to the system level temp folder, which means it has access to that as the apache user, or it's chrooted anyway. there is no difference at the php level when it's accessing temp since it's still accessing the same filespace the same way - there aren't two levels of /temp folder normally and most shared hosts don't support it, which is exactly why smf has db sessions in the first place: to bring sessions outside the temp area where they can't be poisoned by other users

holodoc:

--- Quote from: Oya on November 05, 2010, 12:48:18 PM ---when not using db sessions, php writes those as files to the system level temp folder, which means it has access to that as the apache user, or it's chrooted anyway.
--- End quote ---
Well I am not quite sure how we got to sessions in this debate but shared hosting web servers are actually never configured to store session data in the system-wide /temp folder and session.save_path is always configured to point at the chrooted user /temp folder :) I also think that there is really no reason to involve sessions in this debate since configuring them can be performed completely independent from the settings we are talking here about. The same applies for the temporary upload folders etc.


--- Quote from: Oya on November 05, 2010, 12:48:18 PM ---there is no difference at the php level when it's accessing temp since it's still accessing the same filespace the same way - there aren't two levels of /temp folder normally and most shared hosts don't support it, which is exactly why smf has db sessions in the first place: to bring sessions outside the temp area where they can't be poisoned by other users
--- End quote ---
As a chrooted user you will never be able to reach the "real" world (i.e. real /temp) and everything you see is stuff inside your user folder so when you make a request for /temp in PHP you will actually access something like /home/chrooted/holodoc/temp because your script will regard /home/chrooted/holodoc as its base (/) folder. However the issue at hand is not how temporary folders are structured on different web server layouts but the fact that /temp (or /tmp) is almost allays available and accessible on all those layouts :)

Oya:
except that experience disagrees with you - most shared hosts are not so effectively locked down as you think, again this is the reason for having db sessions because for a very long time, /temp was NOT jailed on shared hosts, meaning that every user had access to the real /temp for session storage, or whatever folder - either way, everyone had access to it.

i still know two or three shared hosts that run like that,

holodoc:
@Oya
While I certainly don't disagree with the idea of storing session data inside a database (not to mention the fact that its a very common way to store sessions in the last couple of years) I still fail to understand why do you keep bringing sessions up in this discussion :) Yes they can be stored inside the system-wide temp folder (but they are usually not) and yes they tend to be susceptible to session hijacking if they are stored in that way but here we are not talking about session or any other kind of sensitive data which would present a threat even on a shared hosting where the system-wide temp folder is shared among users.

Why would it be almost impossible for the attacker in this case to do mischief by using any kind of temp folder, even the one that is provided by the system? Well it would be enough to say that whatever mod files are extracted during the installation process they would not live long enough to even present the attacker with the opportunity to alter them because it would take the forum software at most a couple of seconds to extract the files into the temp folder, use them and delete them after the installation process :) Even if your SMF installation doesn't delete the files the next user which installs the same modification will still overwrite the residual files in the temp folder with the fresh, completely untainted and trusted, version of the files.

Regarding shared hosts which don't enforce jailing of their users I usually don't participate in any kind of discussion which involves discussing the quality of web hosting providers. Why not? Because today if you decide to throw a stone in any direction you will most certainly going to hit a person or a company that provides web hosting services :) To cut the long story short, its up to you to choose what level of quality you want for your web site, forum or custom application and you are most certainly not going to use a free web hosting provider (which most certainly doesn't provide user jailing) to host a web site or application you consider to be important. If that would be the case then all of the major companies would host they corporate web sites on free web hosting providers too ;D

Navigation

[0] Message Index

[#] Next page

[*] Previous page