Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there any special steps that should be taken to secure Gallery? Specifically, I currently have the Fedora RPM gallery2-2.3-1.fc8 installed. I do have selinux enabled in targeted mode, which is a good layer of protection. I found the Gallery security documentation. I was just wondering if there was anything else I should look at to ensure that this is secure against external attack.

I am far less worred about local attack. I just want to ensure that exposing this to the public internet won't get my server hacked.

share|improve this question
up vote 3 down vote accepted

Gallery has raised money for security audits of the core packages. They do a pretty good job. I'd trust them more then wordpress for example. Both products do suffer from the same problem, none of the plugins are sandboxed and often do stupid things. Keep light on the plugins (the core or most popular ones) and you'll be alright.

Also of course, try to run each application as a different user, to contain security breaches. And keep the gallery data folder out of the document root. Gallery also likes memory so if you can turn your php memory limit up a bit it always improves performance.

share|improve this answer

The Gallery security docs are pretty thorough; if you secure Gallery that much, your main concern should be other avenues of attack like bugs in php itself or in ssh or whatever other services you're running.

share|improve this answer

Gallery itself seems fairly secure, just ensure you run the latest stable versions and keep on top of updates.

share|improve this answer

Agreed; the Gallery team is pretty good about keeping their code well maintained.

That said, the best security for any PHP app is the server itself. Make sure you're not running Apache as root, don't waste time with so-called safe_mode, disable directory indexes, don't leave backup files (such as vi's files around where a config file containing your mysql password may be stored) around.

share|improve this answer

With SELinux targeted policy enabled you should really check what SELinux context/domain your network facing (or localuser facing) services are running as. Try the -Z option for ps. if it is unconfined_u:unconfined_r:unconfined_t it isn't doing much for you. You can change this of course by installing the right policy module is installed (see tools such as seinfo, semanage, semodule). If you don't have a defined policy for the service/app then you need to create your own. Tools exist now that help this, such as SLIDE (eclipse plugin) and seedit. You will need to look at your audit logs (typically /var/log/audit/audit.log)

share|improve this answer
+1. I didn't know about the -Z option to ps. Looking, there is very very little running as not-me that is unconfined. It's mostly bash (from a single su session) and a few custom scripts that are not internet-facing. Everything else running that is not from my non-root GNOME session is confined. – Eddie Jun 20 '09 at 18:42
very very quick and dirty one liner to get current state of ip4 sockets. This is just for the idea, customize to get the information you want. for pid in lsof -i 4 | awk '{print $2}' | sort -u | head -n -1 ; do ps --pid $pid -Z ; done – rev Jun 23 '09 at 16:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.