Serious Safe Mode Discussion

valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2003-01-05 00:44

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

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Sun, 2003-01-05 08:20

First, an anecdote. Back in July I went to the O'Reilly Open Source Convention and gave a talk on Gallery. While I was there, I wound up sitting at a table with Rasmus Lerdorf, the guy who founded PHP. He's a Gallery user so while we talked about various things, we eventually got around to talking about safe mode, since it's one of the biggest thorns in the side of applications like Gallery. About safe mode Rasmus says "the biggest problem with safe mode is that people use it." And he's right. Safe mode is fundamentally flawed because it's providing security at the application level, instead of at the operating system level. If you can run CGI scripts (which have no comparable safe mode) then you can do all the things that safe mode prevents you from doing. This is like ignoring the locked door (safe-mode PHP) and going in through the nearby open window (CGI). The only situation where safe mode actually provides any security is in the situation where your ISP also denies you any CGI access.

Now, I've investigated many, many ISP setups (you would not believe the number of people who have given me ftp and ssh access so that I could debug gallery on their environment. The number is in the hundreds) and very, very few of them deny you any CGI capability because that's what people are paying to use. Problem is that many ISPs don't take the time to implement a proper solution. They pick the easy one, and it costs you (and me) a great deal of trouble. The right solution is to create a chrooted jail for each account. This provides true security at the operating system level. I'm seeing more and more ISPs take this approach. Once you get to this point, you don't need to use safe mode, open_basedir, or other snake oil security solutions because you have a truly secure environment. You can let the user run whatever scripts he or she wants -- it won't impact server security in the least.

So, having said that -- I'm not that concerned about safe mde. If G2 works with safe mode on, I'll be happy about it. But if it doesn't work with safe mode on I'm not going to jump through ridiculous hoops to make it work. You, the user, should complain to your ISP about their inferior security and push them to improve their offering. If your ISP cannot do that, we'll be sure to provide a list of ISPs that will.

In the meantime, here's the current list of reasons why I think we may not be able to support safe mode:

  • You cannot use pipes or redirects when executing system calls which is painful (though not insurmountable) for the graphics manipulation packages like NetPBM that expect to use pipelining.
  • mkdir() will not allow you to create new directories unless the parent directory has the same UID as the process being executed. This means that Gallery will not be able to create it's data directories under the top-level "albums" directory that you created using ssh/ftp -- your ISP will have to chown the top-level directory for you in order for you to successfully install Gallery.
  • You cannot call set_time_limit() in safe mode, which means that Gallery cannot do anything that takes longer than 30 seconds (or whatever the server is configured to allow). This means that at the 30 second mark, your operation will be interrupted. Since the most commonly used database (MySQL) in its most commonly implemented setup (MyISAM) does not allow transactions, this means that you virtually guarantee data corruption when your long operation fails.

Let the flames begin.
-B[/]

 
ill
ill's picture

Joined: 2002-08-15
Posts: 756
Posted: Sun, 2003-01-05 08:47

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.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2003-01-05 11:40
Quote:
Let the flames begin.
-B

hopefully not :smile:

Quote:
    <LI> You cannot use pipes or redirects when executing system calls which is painful (though not insurmountable) for the graphics manipulation packages like NetPBM that expect to use pipelining.
    <LI> mkdir() will not allow you to create new directories unless the parent directory has the same UID as the process being executed. This means that Gallery will not be able to create it's data directories under the top-level "albums" directory that you created using ssh/ftp -- your ISP will have to chown the top-level directory for you in order for you to successfully install Gallery.
    <LI> You cannot call set_time_limit() in safe mode, which means that Gallery cannot do anything that takes longer than 30 seconds (or whatever the server is configured to allow). This means that at the 30 second mark, your operation will be interrupted. Since the most commonly used database (MySQL) in its most commonly implemented setup (MyISAM) does not allow transactions, this means that you virtually guarantee data corruption when your long operation fails.

Thanks for your precise answer.
As for the first two points I think you could easily code around the limitations of safe mode.
But the third one is a real problem. Too many ISPs are still using MYISAM and hence are not providing transactions. And when uploading images, generating thumbs, ... you easily pass the 30 secs mark.
But with a remote tool like Gallery remote you have a master process which could observe this process, send one picture at the time and take care of data integrity.
But the Gallery Remote tools should be an additional solution, right?
I agree with you, the gallery needs Safe Mode off, too bad.

cheers - Andy[/]

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Tue, 2003-01-07 11:05
Quote:
But with a remote tool like Gallery remote you have a master process which could observe this process, send one picture at the time and take care of data integrity.

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.

 
pawmarks
pawmarks's picture

Joined: 2002-08-19
Posts: 19
Posted: Sat, 2003-01-11 13:33

An alternate solution to safe mode woes:

1. Grab your own co-lo. It costs $99/mo for 60gig box on a multi-gigabit connection, AND YOU CONTROL THE WHOLE BOX!! 400 GIG of traffic, no restrictions (including adult)

2. pimp out the box to 20 friends - now they have $5/mo php/mysql access and you can even offer em shell accounts if you dare <snicker>

3. go beyond 20 friends (the box will support 100 or more easily) and pocket the diff or reduce prices.

4. GET OVER IT ALREADY!! STOP WHINING ABOUT SAFE MODE!!

//step off soapbox here

 
Ansolon
Ansolon's picture

Joined: 2003-01-14
Posts: 46
Posted: Tue, 2003-01-14 03:36
Quote:
Grab your own co-lo. It costs $99/mo for 60gig box on a multi-gigabit connection, AND YOU CONTROL THE WHOLE BOX!! 400 GIG of traffic, no restrictions (including adult)

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

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Tue, 2003-01-14 04:15

Pawmarks, if you're going to answer Ansolon please do so in the Gallery Hosting forum. Let's keep this thread on-topic about safe mode. Thanks.

 
Ansolon
Ansolon's picture

Joined: 2003-01-14
Posts: 46
Posted: Wed, 2003-01-22 02:48

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...

 
Caddy

Joined: 2003-01-27
Posts: 1
Posted: Mon, 2003-01-27 06:16

I think storing the images in the db would solve a lot of the headaches of creating new directories, files, etc. Also, it would keep the images secure... and only people who are supposed to see them could see them. I dunno if it would be feasible at this point... just a thought :smile:

 
alindeman
alindeman's picture

Joined: 2002-10-06
Posts: 8194
Posted: Tue, 2003-01-28 23:09

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...

 
beckett
beckett's picture

Joined: 2002-08-16
Posts: 3474
Posted: Tue, 2003-01-28 23:39

That's correct. Storing image data would make the DB prohibitively large. Remember G2 will allow you to store images *anywhere* on your server, so if you place them outside of your web directory, they'll be very secure, and inaccessible except through Gallery.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2003-02-01 23:52

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:

 
phineasflapdoodle

Joined: 2003-05-08
Posts: 11
Posted: Wed, 2003-05-14 19:37

"The right solution is to create a chrooted jail for each account. This provides true security at the operating system level. I'm seeing more and more ISPs take this approach. Once you get to this point, you don't need to use safe mode, open_basedir, or other snake oil security solutions because you have a truly secure environment. You can let the user run whatever scripts he or she wants -- it won't impact server security in the least."

Well Bharat, you hit the nail right on the head, and that's exactly how we run our hosting system, with safe mode OFF, and a chrooted jail for each account. It's THE way to go.

By the way, this is Stephen Jones here, of the old "livetopaint.org" (not on-line anymore, and won't be) site. I've been off-line for quite some time, but am back now, and it's great to see that G2 is still pushing ahead. Our new site is almost done, but since it's not quite done, I'll leave this post link-less. :-)
I hope to be able to help with the graphical user interface of G2, so I'll get the code soon, and poke around it.

 
nick77
nick77's picture

Joined: 2003-07-22
Posts: 77
Posted: Mon, 2003-08-04 19:47

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); ***/

?>

 
alindeman
alindeman's picture

Joined: 2002-10-06
Posts: 8194
Posted: Mon, 2003-08-04 21:31

That's quite a hack and some people don't even use FTP. Sorry, but this really isn't portable enough (or fast enough, for that matter) to actually be used....

 
nick77
nick77's picture

Joined: 2003-07-22
Posts: 77
Posted: Tue, 2003-08-05 15:07

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?

 
alindeman
alindeman's picture

Joined: 2002-10-06
Posts: 8194
Posted: Tue, 2003-08-05 15:25

You can't put something like this into a product like G2. Yes, it's a creative idea, but it's not portable and it's not robust code. Thanks for the idea, but I can tell you right now it probably won't go in to G2. Also, there's the issue of exec() being restricted, which your code can't help.

I don't use FTP for my site. I modify my site either by using ssh / sftp. Some of my sites are checked in using cvs, which then gets updated from the server.

 
nick77
nick77's picture

Joined: 2003-07-22
Posts: 77
Posted: Tue, 2003-08-05 15:45

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

 
joe222

Joined: 2003-11-29
Posts: 1
Posted: Sat, 2003-11-29 14:10
bharat wrote:
The right solution is to create a chrooted jail for each account. This provides true security at the operating system level. I'm seeing more and more ISPs take this approach. Once you get to this point, you don't need to use safe mode, open_basedir, or other snake oil security solutions because you have a truly secure environment. You can let the user run whatever scripts he or she wants -- it won't impact server security in the least.

Could you point me in any direction? I would like to convince my ISP that this is an option. It would be nice to have, if nothing else, pointers as to what would be required to create chrooted jails for each account.

And while at it, could Gallery be installed by the ISP to be offered as a service? That is, one installation allows several customers with different domains to access an instance of Gallery under theirdomain.com/gallery, with the main code shared and allowing the ISP to keep safe mode on. Just like ISPs do with SquirrelMail, PHPMyAdmin, and so on, one installation serving several distinc clients. This would/could clear the way for ISPs that insist on having safe mode on, like mine.

Jose

 
nilsjeppe

Joined: 2004-02-13
Posts: 7
Posted: Fri, 2004-02-13 10:56

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

 
jmullan
jmullan's picture

Joined: 2002-07-28
Posts: 974
Posted: Fri, 2004-02-13 20:14
nilsjeppe wrote:
You can not handle all security on the OS level.

No one will argue with you there.

nilsjeppe wrote:
Anybody who says that security is purely a matter of the OS is a complete fool.

No one said that, either.

nilsjeppe wrote:
SafeMode wouldn't be necessary if people could write decent applications and php wasn't so damn easy to exploit without safemode.

Well, it's not the hacking of php that is really the problem here. Safe mode generally protects one user from another user on the same system. The web server has to be able to read the files that it is going to serve, and if every user is using the web server, then anyone could look at anyone else's web files. Not such a big deal for things available on the web, but one user could find out another user's database password, or view information that was protected by (for instance) htpasswd.

nilsjeppe wrote:
Why, for example, does gallery have to execute binaries? You could easily use gd or something, no?

It doesn't have to use binaries. G1 could be modified to use gd, but no one wants to do it. Someone does want to add a gd module to G2, but I forget who.

nilsjeppe wrote:
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).

Why leave the door unlocked? A chroot jail isn't everything, but it is very useful.

nilsjeppe wrote:
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.)

Yep, you sure do. I wouldn't host sensitive data in a place like that. Not that any of my data is all that sensitive.

nilsjeppe wrote:
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.

I think that G2 will be more likely to work in safe mode, but bharat did already raise some possible issues. Safe mode is in mind, but it isn't our only consideration.

nilsjeppe wrote:
What next, want me to allow register globals again?!

For G1, yes. :) We do our own global variable trickery. G2 handles things better.

nilsjeppe wrote:
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.

Saying "you people" makes you sound a little flamey.

G1 under safe mode "ain't our problem".

We are considering G2 under safe mode. It still "ain't our problem," but we are considering it, and would support any efforts to come to a real safe mode resolution. I don't think that anyone on the testing team has a development environment where safe mode is on. I know that I will probably never set up safe mode on a server that I run.

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

You mean that you won't, right? I will reiterate that someone somewhere has the intention to make a GD module.

I'm sure that's not the only issue that safe mode will raise. Safe mode can even be set up dfferently per install. Some things can be restricted on one server but allowed on another. It's a tangled, difficult web.

Thanks for the input, we appreciate it!

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Sat, 2004-02-14 08:26
nilsjeppe wrote:
Hi,
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.

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.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-02-14 13:04
bharat wrote:
Nils, I believe you're totally missing the point. What you need to be asking yourself is, "what benefit does safe mode provide?"

not really, he's looking at the issue from a totally different perspective.
yours is: "why use safe mode"?, his is "safe mode is used on most hosts by default, how do we get G2 working on these servers?"

fact is that there are enough webhosts out there who disable safe mode if requested. but it's not very helpful to the success of Gallery to have such a requirement. java based CMS's like cocoon will never be adopted by the masses just because there are no webhosts which offer java for an affordable price.
on the other hand you have something like phpnuke or phpbb. all you need is a db.

 
nilsjeppe

Joined: 2004-02-13
Posts: 7
Posted: Thu, 2004-02-19 11:14
jmullan wrote:
nilsjeppe wrote:
SafeMode wouldn't be necessary if people could write decent applications and php wasn't so damn easy to exploit without safemode.

Well, it's not the hacking of php that is really the problem here. Safe mode generally protects one user from another user on the same system. The web server has to be able to read the files that it is going to serve, and if every user is using the web server, then anyone could look at anyone else's web files. Not such a big deal for things available on the web, but one user could find out another user's database password, or view information that was protected by (for instance) htpasswd.

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...

jmullan wrote:
It doesn't have to use binaries. G1 could be modified to use gd, but no one wants to do it. Someone does want to add a gd module to G2, but I forget who.

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

jmullan wrote:
Why leave the door unlocked? A chroot jail isn't everything, but it is very useful.

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

jmullan wrote:
Yep, you sure do. I wouldn't host sensitive data in a place like that. Not that any of my data is all that sensitive.

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.

jmullan wrote:
I think that G2 will be more likely to work in safe mode, but bharat did already raise some possible issues. Safe mode is in mind, but it isn't our only consideration.

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.

jmullan wrote:
Saying "you people" makes you sound a little flamey.

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" :)

jmullan wrote:
We are considering G2 under safe mode. It still "ain't our problem," but we are considering it, and would support any efforts to come to a real safe mode resolution. I don't think that anyone on the testing team has a development environment where safe mode is on. I know that I will probably never set up safe mode on a server that I run.

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.

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

You mean that you won't, right? I will reiterate that someone somewhere has the intention to make a GD module.

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.

jmullan wrote:
I'm sure that's not the only issue that safe mode will raise. Safe mode can even be set up dfferently per install. Some things can be restricted on one server but allowed on another. It's a tangled, difficult web.

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

 
nilsjeppe

Joined: 2004-02-13
Posts: 7
Posted: Thu, 2004-02-19 11:38
bharat wrote:
Nils, I believe you're totally missing the point. What you need to be asking yourself is, "what benefit does safe mode provide?"

As valiant points out, I am just looking at it from a different perspective. You want safemode to go away, and I know that it isn't going to - and I am trying to convince you that the energy spent on wishing that it would is pretty much wasted =)

bharat wrote:
Gallery 2 is designed from the ground up to be as secure as possible. [...]

Oh, I have no issue with your design. I didn't shift through the code myself, I am not that fluent in php.

bharat wrote:
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.

Right. No argument about that. Note I never claimed that safe mode automagically makes for a secure setup. Safemode is a safeguard against edumb users. The kind that uses an url parameter to include a file from the filesystem. Too many badly written php scripts are out there, and too many people who think they know what they are doing.

Some people still use "password" as their password, this doesn't mean that a pw check on login is useless, right?

bharat wrote:
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.

That's a lot better than nothing - and it's sufficient for any normal end-user setup.

bharat wrote:
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.

Sweet.

bharat wrote:
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).

Set the php parameter max_execution_time to 120 or something else that is sufficient. That is hardly a "ridiculous" solution, especially since afaik it can be done on a per virtualhost setting (or even per directory/location. I forget. I am getting old). If the php script isn't done in a maximum time, it should be killed anyway to deal with runaway scripts. Better to disable the users' ability to circumvent that safeguard. (If I missed part of the point of set_time_limit please bear with me.)

bharat wrote:
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.

Eh, you consider not being able to create files in a directory you do not own "ridiculous"? No offense, but do you want me to abolish file permissions on my system next? I am sure that is not what you meant to imply... but I have the impression you just shot yourself / your argument into the foot ;-)

bharat wrote:
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.

And that is exactly the point: You should definitely include safemode considerations into your development agenda, because not taking care of safemode compatibility hurts your adoption rate. And it's probably a much better idea to deal with these limitations from the start instead of hacking something together later.

- Nils

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2004-02-20 00:44
nilsjeppe wrote:
bharat wrote:
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.

Right. No argument about that. Note I never claimed that safe mode automagically makes for a secure setup. Safemode is a safeguard against edumb users. The kind that uses an url parameter to include a file from the filesystem. Too many badly written php scripts are out there, and too many people who think they know what they are doing.

Some people still use "password" as their password, this doesn't mean that a pw check on login is useless, right?

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.

nilsjeppe wrote:
bharat wrote:
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).

Set the php parameter max_execution_time to 120 or something else that is sufficient. That is hardly a "ridiculous" solution, especially since afaik it can be done on a per virtualhost setting (or even per directory/location. I forget. I am getting old). If the php script isn't done in a maximum time, it should be killed anyway to deal with runaway scripts. Better to disable the users' ability to circumvent that safeguard. (If I missed part of the point of set_time_limit please bear with me.)

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.

nilsjeppe wrote:
bharat wrote:
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.

Eh, you consider not being able to create files in a directory you do not own "ridiculous"? No offense, but do you want me to abolish file permissions on my system next? I am sure that is not what you meant to imply... but I have the impression you just shot yourself / your argument into the foot ;-)

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.

nilsjeppe wrote:
bharat wrote:
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.

And that is exactly the point: You should definitely include safemode considerations into your development agenda, because not taking care of safemode compatibility hurts your adoption rate. And it's probably a much better idea to deal with these limitations from the start instead of hacking something together later.

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).

 
SupermanInNY

Joined: 2004-04-14
Posts: 2
Posted: Wed, 2004-04-14 23:52

Hey,.. I'm kinda of a newbie here, but I happen to be hosting provider.
Here is my scenario:

I have a very secured server.
Jailshell for SSH and other goodies all over.
I'm one of those paranoid people who don't want their customers to be upset with them for having a compromise on the security and privacy of their well paid for websites.
What do I mean?
Well. there there several issues to onsider. Let's examine the basics:

Here is a short code for demonstration having safe_mode in the disabled/off position:

<?php

system ("cat /etc/passwd");

?>

isn't this a pretty site?

If you are the only user on the server,. forget about the safe_mode etc.
But, sorry,. I have a server that is serving multiple customers none of them wants to be revealed and certainly not exposed.

Mambo came with a fix for the safe mode. Perhaps it is not the coolest
thing in the world.

http://forum.mamboserver.com/viewtopic.php?t=1537

Perhaps is solves only 50% of the people's trouble.
Perhaps it doesn't solve everything.
All is possible.
But,. it does overcome directory creations etc.

Second thing:
While safe_mode is on... I can still provide safe_mode_exec_dir and place some symbolic links to needed binaries. Of course not all binaries are "allowed" and welcomed. For instance "cat", "ls" etc.... are not going to have symbolic links
I would think of different ways to go about resolving issues with the safe mode.
Think of what essential features are a must have in the gallery and possibly issue patches to address those needs.. or take them out and create a SafeModeGalleryLite1.0 so that you can still get 80% of the functionality working until you figure a way to do the additional 20%.

just my $0.04 (I'm a big spender.. I double everyone elses contributions).

-Alon.

 
virshu
virshu's picture

Joined: 2003-09-13
Posts: 314
Posted: Thu, 2004-04-15 02:13
Quote:
Here is a short code for demonstration having safe_mode in the disabled/off position:

<?php

system ("cat /etc/passwd");

?>

isn't this a pretty site?

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

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2004-04-15 17:06
Felix, - typo wrote:
If your host has PHP safe_mode enabled you have two choices - give up on Gallery, or move elsewhere. I know what my choice would be!

Would be a nice headline for an ad / poster ;)

 
SupermanInNY

Joined: 2004-04-14
Posts: 2
Posted: Fri, 2004-04-16 15:41
Quote:
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?

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.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Sat, 2004-04-17 01:38
SupermanInNY wrote:
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.

Sure, if you're using mod_php. suEXEC is only going to change the effective uid of the process if you use it in conjunction with the PHP as CGI. That is the design of suEXEC (you might want to review their documentation). When you use PHP/CGI with suEXEC each php.cgi process runs as the effective userid of whichever user you've specified in your suEXEC configuration, based on your vhost setup.

SupermanInNY wrote:
Apache is king of the hill.. he can go anywhere users can't.

That's only true if you run Apache as root and don't restrict its effective user id to nobody, as is recommended for a production install. If you configure it correctly, it runs as the "www" (or "nobody") user which has a restricted set of permissions as configured by your operating system and filesystem.

SupermanInNY wrote:
So writing in perl is strongly urged as it is limited by the CGI wrapper.
PHP,.. bypasses that limit.

So anything that PHP as CGI can do, Perl as CGI can do. But if you're running in safe mode, then Perl/CGI can do plenty of things that PHP/CGI won't do. So a hacker is just going to use Perl to get around whatever restrictions you implement in PHP. Door locked, window open.

My response to this is as always. I'm willing to consider supporting safe mode, but only after we build a working application. I will not design Gallery to work in the busted safe mode environment because it makes no sense to me to design an application to run in the kind of crippled VM that you can create by enabling safe mode. We want Gallery to work everywhere, so if at some future date we have more resource cycles and can figure out a way to adapt Gallery to work in safe mode, then I'll certainly try to make it more compatible. But in the meantime, the resources on G2 are limited and very busy just making a good application. If a talented and competent engineer shows up and is motivated to adapt the G2 framework to be reliable and robust in the face of safe_mode then we'll certainly be happy to have that person work on it.

 
aakoch

Joined: 2004-04-21
Posts: 4
Posted: Wed, 2004-04-21 18:37

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

Quote:
Sorry, but for security reasons we cannot turn off Safe Mode for PHP under any circumstances.

Turning off Safe Mode for any user will give that user root access to the server with permissions to act as server administrator. The only way we can provide PHP with Safe Mode disabled is to through a dedicated server.

Is that just bunk?

Thanks.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Thu, 2004-04-22 08:50
silent_l wrote:
I asked my host to turn off safe mode and got this response:

Quote:
Sorry, but for security reasons we cannot turn off Safe Mode for PHP under any circumstances.

Turning off Safe Mode for any user will give that user root access to the server with permissions to act as server administrator. The only way we can provide PHP with Safe Mode disabled is to through a dedicated server.

Is that just bunk?

Pretty much. In order for turning off safe_mode to allow the user root access, they must have done the staggeringly insecure thing of allowing Apache to run as root. If they've made a blunder of those proportions, then safe mode is the only thing preventing any PHP script from being able to wreak havoc on their system. Of course, in order for their system to be secure, they must have disabled all other forms of CGI since otherwise any other CGI would also be running as root.

Frankly, I doubt that they've got Apache running as root. It's far more likely that they have a weak security model (see my first post in this topic) and that a) the person who responded hasn't a clue or b) they want to upsell you to a more expensive server.

 
trippy

Joined: 2004-04-22
Posts: 1
Posted: Thu, 2004-04-22 20:27
Quote:
Quote:
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.

Sure, if you're using mod_php. suEXEC is only going to change the effective uid of the process if you use it in conjunction with the PHP as CGI. That is the design of suEXEC (you might want to review their documentation). When you use PHP/CGI with suEXEC each php.cgi process runs as the effective userid of whichever user you've specified in your suEXEC configuration, based on your vhost setup.

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.

 
virshu
virshu's picture

Joined: 2003-09-13
Posts: 314
Posted: Fri, 2004-04-23 02:58

trippy, you essentially rehashed my conversations that I had with my old host (who were running mod_php and safe mode) and new host (who are running php/cgi) :lol: There are two other issues that I want to mention:

Quote:
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

It's not like the hosts with correct solution are more expensive! Moreover, the hosts with crappy solutions are more likely to have other problems, just because they have less clue about what they are doing! So, think about switching!

Second, by running PHP/CGI you lose the ability to integrate Apache authentication in your PHP programs. Since Gallery is not using it (and this is Gallery forum) - I am not going into details of what it is. But just by switching from mod_php to PHP/CGI you are making this compromise. I think it's well worth it, though! I switched the host 3 months ago and don't have any regrets!
Felix
http://gallery.rabinovich.org

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-04-25 16:43
virshu wrote:
Second, by running PHP/CGI you lose the ability to integrate Apache authentication in your PHP programs.

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

article wrote:
Despite the PHP manual that says HTTP Authentication hooks in PHP are unavailable when running the CGI version of PHP, on our system they will work, even when you are running PHP as a cgi.
[........]

 
virshu
virshu's picture

Joined: 2003-09-13
Posts: 314
Posted: Mon, 2004-04-26 00:55
Quote:
Despite the PHP manual that says HTTP Authentication hooks in PHP are unavailable when running the CGI version of PHP, on our system they will work, even when you are running PHP as a cgi.

Good for them - it ain't working on mine :evil:

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2004-04-26 10:59

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

 
testguy

Joined: 2004-05-27
Posts: 18
Posted: Fri, 2004-10-01 13:23

Found some interesting stuff and without chitchat, just some interesting links from securityfocus for those, having their own server(s):

Securing PHP
http://www.securityfocus.com/infocus/1706

Securing Apache
http://www.securityfocus.com/infocus/1694

Securing Apache 2
http://www.securityfocus.com/infocus/1786

Securing MySQL
http://www.securityfocus.com/infocus/1726

Ron :)

 
beckett
beckett's picture

Joined: 2002-08-16
Posts: 3474
Posted: Fri, 2004-10-01 22:31

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

-Beckett (

)

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-10-30 14:55

I don't need to disable safe_mode, but I was discussing with a dev whether it was possible to disable safe_mode by .htaccess and I couldn't prove it to him that it possible.

I thought to remember that I successfully disabled safe_mode by .htaccess once.
Today, I tried it on my apache2, php 4.39 and I failed.

All sources, the php docs too, say it's not possible to set php_admin_flag safe_mode off in .htaccess, becaue generally, you can't set php_admin_flag's in .htaccess.

I guess I used php_flag safe_mode off, but this didn't work neither when i tested it today.

I've set AllowOverride All on my htdocs dir in the apache conf and for testing purposes, i've set safe_mode On in php.ini. Of course i didn't forget to restart the webserver.

So, all I ask: is it possible?
What webserver configs are required?

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Sat, 2004-10-30 22:00

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).

 
Mezon

Joined: 2004-11-30
Posts: 7
Posted: Wed, 2004-12-01 00:18

I used to work in one of the cheapest web hostings here in czech republic and my experience is this

1) nobody has safe_mode off
2) safe_mode doesn't protect one from a malicious valid user, but mostly from exploitable application bugs - thus, limiting application's capabilities is a must
3) when you have ~1000 users on a server, you really don't want to assign UID to each of them, most "mass" or so-called "cheap" webhostings use one UID for both the ftp account and the webserver (ftp account being chrooted to document root, php running in safe_mode with open_basedir set to users home and CGIs forbidden (of course ))
4) i have seen many complex projects implemented in PHP, banner exchange systems, user-made galleries, chats... most of them deal with image manipulation or creation, user data separation and all without the need to disable safe_mode

Yes, I read the reasons why gallery cannot run with safe_mode, but for a well configured server, this should not be a problem (i'll give it a try as soon as GD2 is supported)

Creating files - no problem, FTP account has the UID of the user running apache (or a setgid bit can be set on dirs)

Resizing images - GD2 should handle that, no need for external programs

ffmpeg support - tricky, but honestly - if somebody needs that, he surely doesn't run on a "cheap" webhosting, does he?

Time limits - this is a problem, there is no guarantee on how much system time a process will get, and because of many flawed products which just keep hogging your server forever, you really want to set max_execution_time to a sane number - but most webhostings will adjust this setting for your needs (don't expect them to give you more than ~360secs though )

Is there any other reason why g(2) can't run with safe_mode=on?

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2004-12-03 05:23

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.

 
Mezon

Joined: 2004-11-30
Posts: 7
Posted: Fri, 2004-12-03 08:34

I don't think you can "ship" G2 without safe_mode compatibility mode...

I'll be more than happy to help, G2 is great :)

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2004-12-03 08:44
Mezon wrote:
I don't think you can "ship" G2 without safe_mode compatibility mode...

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.

Mezon wrote:
I'll be more than happy to help, G2 is great :)

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

 
Mezon

Joined: 2004-11-30
Posts: 7
Posted: Fri, 2004-12-03 10:47

Well, since I can't code PHP (but I can read the logs :)), I guess you will be well informed of my progress :)

btw, about transactions - I think it can be implemented on application level if not supported in the db itself...

 
oliwel

Joined: 2004-12-12
Posts: 20
Posted: Sun, 2004-12-12 12:56

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
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Sun, 2004-12-12 17:24

oliwel, search the forums and read the FAQ

 
oliwel

Joined: 2004-12-12
Posts: 20
Posted: Mon, 2004-12-13 18:09

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....