Serious Safe Mode Discussion

I know, it has been discussed from times to times, but this thread should be ultimate, detailled answer, why you need PHP Safe_Mode in gallery and gallery2.

An argument was that gallery needs the permission to create its own directories.
My suggestion:
When in installed in Safe Mode, all Files are owned by the webserver (or www or whatever).
PHP can chmod directories on the fly to 777 and do what ever it wants. In the end, chmod them back and everything is fine.
Or is there still a problem?
I've ran FUDForum ( http://fud.prohost.org/forum/index.php) in Safe Mode as an NNTP interface (which has to create local files on the fly) and it worked.

Are there other restrictions? Is there no workaround?

It's just that all big ISPs are activating Safe_Mode and you should be able to code a gallery with Safe_Mode enabled.

Thanks - Andy

update - 2006/09/26:
Someone has created a patched version of G2 that works with PHP safe_mode on. Some features are missing of course, but most things work:
Get it at: http://www.netsons.org/viewtopic.php?t=117

Manual instructions to patch the official release of G2 yourself to make it work with safe_mode on:
http://shawking.free.fr/blog/?p=12

I must agree - safe_mode was a try to ease the process of securing a system. True security measures cannot start here and must be taken on the OS-side already. This said, chroot() is the best option on UNIX-based systems. Similar possibilitites are available on other systems - such as IUSR on Windows.

The bigger issue - regarding security - is not safe_mode but register_global. But that's OT, and Gallery does handle this correctly, I believe.

It doesn't quite work that way, unfortunately. All Gallery Remote does is submit HTTP requests to the server. It's possible for it to submit a request that runs longer than 30 seconds, since G2 may do some internal bookkeeping, or the server may be running slow, or who knows what else is going on. :sad:

Sigh. Good ideas, though.

Can you tell me which company provides this dedicated service or write its web adress?

sorry for asking it here...
I have been changed Liv-Tyler.com's server more than 6 times in 8 months because of bandwith usage and 2 times because of safe mode.

Whatever Finally I solved the problem...
Sorry again...

As far as I know, images would still be stored in directories, right? Only metadata would be stored in the database? Correct me if I'm wrong, I need to look more at the G2 code...

lol, yes :smile:
I'd never store lots of binary data in a DB in this case (I used to be Oracle Admin).
Imagine all the extra dependencies of the network design.
But you don't really need for each album an extra directory and the pics must no be stored with their original name.
I'd map all data with the DB and store the pics in some few predefined directories.

anyway - go bharat go, we're waiting for g2 :wink:

this function would replace mkdir() so one problem less;-)

Would be great if it could be used!

Nick

<?

function makedir($root,$newdir,$chmod=755)
{

/* In the root directory will this script add a new */
/* folder $newdir. You can chmod it to your needs. In */
/* safe_mode (and in others you don't need this script */
/* you most likely need 777, so this is the default value*/
/* $root-directory: "yourdomain.com/folder" */
/* (this path already has to exist!!) */
/* */
/* change below to fit your ftp account */

$conn_id = 0;
$conn_id = ftp_connect("ip.add.re.ss");

$login_result = ftp_login($conn_id,"***FTP-USER-NAME***","***FTP-PASSWORT***");
if ((!$conn_id) || (!$login_result)) {
echo "FTP Verbindung falsch. User/PW kontrollieren!";
die;
}

/* Don't change below!!!!!!!!!! */
/* =================================================== */

if ($root == "") $root == "/";

ftp_chdir($conn_id,$root);
ftp_mkdir($conn_id,$newdir);

if ($chmod == "") $chmod = 777;

ftp_site ($conn_id,"chmod $chmod $newdir");

ftp_quit($conn_id);
}

/*** How to call the script***/
/*** (example) *********/

/*** makedir("yourdomain.com/images","newDir",777); ***/

?>

alright, it IS probably a hack but still could save some people some problems. How about an option in the setup screen one can activate if Gallery detects safe_mode and fails installing? It could replace the mkdir() function by the workaround - I think it wouldn't be UNmakable and you're not creating folders all day long, are you?

nick

ps: what interests me: what are people using who don't use ftp?

Not using ftp still doesn't mean not being able to use it, right?

But I agree, it's probably more a hack desperate users can try after G2 is done and it shouldn't influence the proper coding for it. Still I meant it to be worth giving it a thought;-)

Thanks anyway for patient replying

Nick

Hi,

My €0.02:

You can not handle all security on the OS level. What good is a secure OS when people can for example inject sql via url or something. No OS can save you from that. Anybody who says that security is purely a matter of the OS is a complete fool.

SafeMode wouldn't be necessary if people could write decent applications and php wasn't so damn easy to exploit without safemode. Why, for example, does gallery have to execute binaries? You could easily use gd or something, no?

What good is a chroot jail if the application itself gets destroyed? Yeah you protect the rest of the system (maybe - you might be able to break out of the jail anyway). On the other hand, complete jails for each users aren't economical on cheapo hosting systems. (Remember, before you complain: You usually get what you pay for.) Fact is, safe mode exists; fact is, safe mode gets used a lot, so an application like Gallery should be developed with safemode compatibility in mind. What next, want me to allow register globals again?!

This isn't intended as a flame, but I really do think you people are just looking for the easy way out - saying "aint my problem" never really solved anything.

That said, g2 looks pretty nifty. Wish I could use it but it won't execute netpbm or imagemagick...

- Nils

Nils, I believe you're totally missing the point. What you need to be asking yourself is, "what benefit does safe mode provide?"

Gallery 2 is designed from the ground up to be as secure as possible. We take steps to channel all filesystem and database access through choke points where we can audit what is happening. We do the same for all input fields to prevent malicious data from entering the system. We have unit tests designed to verify that this code is functioning properly at all times so that a casual commit won't break it.

However, none of that is really relevant to the problem with safe mode. You need to go back and read my first post in this topic a little more carefully. Safe mode is a complete waste of time unless you disable all other forms of scripting on the server because anything that you can't do in PHP with safe mode on, you can just as easily do with one of the other scripting options. And sadly, most of the ISPs I've seen (and over the course of the past couple of years of doing customer installs and support tickets I've been on hundreds of ISP boxes) turn on safe mode for PHP but don't bother to restrict anything else. All that does is make PHP an inferior solution on that server. It doesn't offer much in the way of safety.

The inability to call exec() is an issue, surely. Yes, you can use GD2 instead of ImageMagick/NetPBM in some cases, but GD2 supports far less media types than ImageMagick/NetPBM so you're restricting yourself to the media types that it supports and the server must be compiled with JPEG, GIF and PNG support built-in just to have those basic types. But without exec, how are you going to make thumbnails out of movies? PHP sure doesn't have support for that so if you can't use ffmpeg, you're out of luck. The fact that we call exec() doesn't make our app any less secure.

But even not being able to call exec is not that a big deal. Walkah is writing a GD2 module and if you use it, you can probably get away with supporting just a few media types and no automatic thumbnails for movies. But what about the problem that safe mode disables set_time_limit() calls? Now you'll have the PHP VM terminating any long-running jobs (like big uploads or imports) in the middle causing data corruption. That sucks because now you've basically got the VM working against you. The only solutions for that are pretty ridiculous (and I've considered several).

There are plenty of other issues, and each one has its own ridiculous solution. Like using ftp to upload files to the server because safe mode disallows you from creating files in a directory that you don't own.

Maybe after we get G2 working to our satisfaction we'll spend a little time trying to make it a little more safe mode friendly, but I can tell you that it's not going to be a priority until G2 is final.

Right, but the OS doesn't do it and won't do it. Afterall, apache's got to read the info. A jail is just a kludge. Ideally, apache would provide its own chroot functionality for various users. It doesn't, so you got to either patch apache, use a kludge, or live with the solution at hand, which is safe mode...

Well, that would be nice, although of course I'll only get excited when the code's available.

And it's a hack that's not better than safe mode. It just shifts the burden someplace else.

We are not talking about sensitive data. We're talking about photo albums, usually by personal users. If you have sensitive data and a secure, dedicated server, then enabling safe mode is probably not that big of an issue.

Of course it is not your "only" consideration. But given the prevalence of safemode setups, making g2 work with safe mode should be handled before g2 is released.

Nah. It's you the g2 developers. I am not part of that group, neither am I a gallery user, so it's "you people"

Fine if you have that luxury. I don't. I need safemode. I can not trust my users enough to live without. I can not do jails for each user because, frankly, I have better things to do with my time. (I host privately, for friends/family/etc, for free, and that makes for bad economics.) Even if I jailed people, I'd still use safemode. Just because.

No, I mean that I can't. Ownership of my binaries is wrong, even if I allowed exec - and I ain't going to chown my imagemagick binaries. I solved all other issues (I think - afterall I couldn't fully test g2) that arose from my safemode setup. If there was - for example - a gd/gd2 module, that probably would solve my remaining issues and I'd join the ranks of gallery2 users.

Of course, and some people don't have php installed either. Can't really help those, right? But the point is that g2 can be made to work with safemode, and it should.

- Nils

The fundamental problem with safe mode is that it cripples the VM and takes away functionality that is useful for a PHP application. This crippling only applies to PHP, and not to other aspects of the system so Gallery won't be able to do things that (for example) a similar script written in Perl could do. I don't feel the need to write this app to work in a crippled environment, especially since as we can tell from our existing user base of hundreds of thousands of installs, that there are plenty of places which allow you to work with safe mode off. As I said before, we may focus on those other configs later but it's not worth my limited time to address it now, before we even have a product.

Even 120 seconds is not enough for some large operations, like mass importing large amounts of data. The point of set_time_limit is to let the script let you know when its hung and when it's not. Safe mode unilaterally takes away that ability, which hamstrings our app and prevents it from completing normally. And since we have to work with non-transactional databases and the VM can cut out at any time, there's no way for us to guarantee data integrity. I'm not willing to spend a lot of time allowing G2 to recover from pain inflicted upon it by a crippled VM. Maybe later.

I think you're missing out on the filesystem permission issue. You're on your server as the "nilsjeppe" user, but Apache/PHP is running as the "www" user. So when you do your install, you create your gallery data directory as "nilsjeppe", but safe mode won't allow PHP to create files/directories inside that directory, even though it's the directory that we are specifically setting aside for this purpose and we have set the filesystem permissions to allow writing to it. This is something legal and desireable that we're trying to do that safe mode prevents us from doing.

If I had unlimited resources, I'd definitely take it into account. But I don't, and I have to prioritize. If you want this to happen, I'm all for it, but somebody has to cough up another couple of qualified developers to work on it. This is a useful discussion, and I'm not against having it. But unless I get more help on the project, I have to prioritize the work according to the time I have available and right now my first and foremost priority is getting the product to the point where we can release it into our standard environment (which is with safe mode off).

Could you elaborate, what's the problem with that :o ? OK, let me rephrase the question before I get killed... Who are you concerned about when you want to prevent the code like that? Your customer who put this code on his site? It wasn't the hacker; and it wasn't the clueless newbie that put up that page! The guy certainly knew what he was doing and felt that he was entitled to do that for having a well paid for websites. And by the way, before you get too concerned about other customers on your server - if you are running jailshell the only "human" id that he would be exposing is his own! So, where does compromise of security and privacy come in?

So, you enabled safe mode in PHP, and he will write it in Perl. As Bharat pointed before, safe mode will give you false sense of security unless you disable all scripting on your site. If you want to host static pages only - that's fine; but that's a different mark from the one Gallery is targeting. I realize this topic started with the same arguments for the second time - but I had a conversation recently with my hosting provider; and I move elsewhere. I would have no problems saying "In order to run Gallery you need safe mode disabled". If your host has safe mode enabled you have to choices - give up on Gallery, or move elsewhere. I know what my choice would be!

Felix

Some facts:
JailShell work great in the Shell environment.
Galley doesn't work in the shell environment.
SuExect limits Cgi scripts to run with UID of the user.
However,.. when you run it with the PHP and the calls are made via the web,.. the UID used is the Apache Server's ID.. and NOT the UID of the user.
Apache is king of the hill.. he can go anywhere users can't.
So writing in perl is strongly urged as it is limited by the CGI wrapper.
PHP,.. bypasses that limit.

My Other paying customers don't like to share their identity.
I've known too many inside hacker.. more than external heckers.
That means,. my well paying customers will first attempt to sniff around my own server and search for exploits. Once found...they go after the next target,... the other well paying customers who are not even aware of this issue.
Just yesterday there was a crime bust agains a group of 5 teenagers who found an exploit in a server and stoll credit cards from the various other clients.
Do you see a problem there? I certainly do.
The sample code I just gave.. can be expanded to show database usernames and passwords, to show login and password details of other customers and you know what you can do with that. You can run system calls to issue regular display commands like: vi, less, cat,.. all very innocent calls.
If you explain this situation to other well paying customers, you will see your paying customer list shrink in a heartbeat.
The fact that some users are not aware of this, doesn't mean it goes unnoticed by hackers.

I asked my host to turn off safe mode and got this response:

Is that just bunk?

Thanks.

I'm glad this came up, because I feel it was badly explained earlier in the thread. As Rasmus Lerdorf said, "safe mode" is pointless (although it is a reality many people have/choose to deal with with their hosts). It's not as simple as saying that CGI will let you do anything that "safe mode" restricts though...

The reality is that most (all?) hosting companys have the sense to use suEXEC for CGI. To do otherwise is to be incompetant. With suEXEC, CGI's run as the owner of the script (i.e the customer). They can only read and write from/to files that the owner has access rights to. If they can read or write from/to any files that do not belong to them (i.e. that belong to another customer) the other customer HAS SCREWED UP. The other customer has set the permissions on those files to be world readable/writable, and can only blame theirselves. So, ignoring local root exploits and similar nastiness, suEXEC CGI's are safe.

The problem lies in the fact that most hosts are clueless with regard to PHP (actually, it's also related to the fact that most linux distributions do CGI the right way and PHP the braindead way, so the hosts don't necessarily know how to do CGI properly either, it may have just worked for them out of the box). Most hosts that I have seen (and I recognise that bharat has seen *many* more hosts than I have, so he can either confirm or refute what I'm saying here) use mod_php. mod_php is wonderful if a single site/user is running off a webserver, it's wonderful because it's fast as a result of being built into the webserver. But security-wise it sucks completely. Everything is run by the same user as the webserver. So any of the files that one customers script can access, can be accessed by *any* other customer. Do I need to say again that this is moronic?

The hacky (crappy) solution to this is "safe mode". And it sucks, because all it does is provide a false sense of security. The correct solution is to use PHP/CGI, as bharat mentioned above. chroot jails provide extra protection, but are not the main thing necessary. The major issue is to get PHP scripts running as the user who owns them and NOT THE WEBSERVER.

Summary response for people having "safe mode" issues:

If you are having "safe mode" issues, there are two possible setups you are in. One is mod_php, the other is PHP/CGI. If you are in the mod_php situation, you don't want "safe mode" removed. Really. It'll allow other customers to do whatever the hell they want to with your files ("safe mode" won't completely protect you from this either, but it's one layer of protection). If you are in the PHP/CGI situation, "safe mode" is pointless. The only person it is protecting you from is yourself. If your host can't see this, they are clueless. Find another one, fast.

sure? ;)
http://www.modwest.com/help/kb5-103.html

virshu, tried the solution from the link from above? it's not the php manual way of doing it.

I'll bookmark those. Care to give a quick paragraph summary of the highlights and how it can apply to Gallery?

-Beckett (

)

valiant, as of ini_set man page the safe_mode setting is scope PHP_INI_SYSTEM, which is described as "Entry can be set in php.ini or httpd.conf". So this is the documented way.

If it worked on some previous versions to turn it on/off in .htaccess, this was probably a bug and shouldn't be relied on. I.e. there is a recent bug#29695 that refers to the behaviour of overriding a admin-flag with "php_flag" in .htaccess.

The only way I can think of having the user able to specify it is to include a httpd.conf-snippet from the users's directory into your own httpd.conf, where he can adjust settings in his <VirtualHost>. This can be risky, but should make him able to set safe_mode off whenever he wants to (after you reload apache).

I understand your argument, and why you're making it. I think that we will eventually make more of an effort to support safe mode in Gallery 2. But it is not now, and will not be a higher priority than creating a solid product, so we are not going to worry much about safe mode until at least G2.0 ships. We're too resource constrained to do anything else.

At the point that G2 ships, I'll revisit this discussion. If in the meantime, you'd like to help us out by doing some preliminary work on creating a portable solution to safe mode issues (detecting disabled functions that we require, updating GalleryPlatform to detect pipe usage and use temp files instead, modifying our framework to detect when we're running out of time and wrap things up so that we don't get data integrity issues) we'd be happy for the assistance.

Of course we can! And we probably will. Gallery 1.x does not work with safe mode on and while that may have been an impediment for some, it has not been a problem for the hundreds of thousands of websites that are currently using it.

Outstanding. Keep us abreast of your progress (but it's probably best to do it in a new forum topic).

Hi Folks,

I use G1 now for 2 years and must say G2 is coming up great - BUT the Safemode thing is an anger and I am seriously lookng for another prodct.
@bharat: respect for your work, but your attitude regarding safe_mode is a hit in the face for everyone contributing to the system...

I own some webservers and must tell people why they cant run gallery by themself due to safemode - yes I know about jails and co but it is not possible to setup jails for every user...

We run safe_mode only for preventing users from running system calls across the system what IS a security issue even if apache runs as nobody - BUT we put some binaries like ImageMagick into aspecial dir that can be executed with safe_mode enabled and allow mkdir/filesystem access with appropriae uid/gid setups - so I dont see any big issues of G2 supporting safe_mode - perhaps with some restrictions, but thats better than not running G2...

So if anyone can point me to the right pieces of code that are affected by safemode I will review them and try my best.

regards

Oliver

mindless, I read the FAQ and digged into the Forum 2 days, but I cant find the right places in the code - so I need some hints....