Photo Organizer

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Backend / Core
  • Assigned To
  • Operating System Linux
  • Severity High
  • Priority Medium
  • Reported Version 2.36
  • Due in Version 2.37
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by kaz - 2010-08-10
Last edited by pizza - 2010-08-12

FS#435 - Security problem: world readable files in /tmp (and maybe elsewhere?)

I've noticed that in various situations, Photo Organizer creates files in /tmp.
These have loose permissions due to an inadequate umask.

What's the point of Alice making her pictures private, so that Bob can't
see them, if Bob has a shell account on the box and can see Alice's
data as it passes through /tmp?

My /var/lib/photoorganizer-data directory behaves the same way.
Everything under that is rwxr-xr-x or rwxr--r--.

The data is correctly owned by the apache user account (www-data
in my installation) but files should should be rw-------,
and directories and rwx------.

Is this something that can be done globally with PHP or some Apache2
umask setting?

Closed by  pizza
2010-08-12 14:26
Reason for closing:  Fixed
Additional comments about closing:  This is as fixed as it's going to get: * All files and directories explicitly created by PO have explicitly-set permissions (700/400) * A umask of 0077 is now set globally so that all tempfiles (and intermediate files created by external helper tools) will be owner-accessible only. Unfortunately depending on the PHO installation this may be overridden by another PHP execution thread.
pizza commented on 2010-08-10 13:21

In all fairness, potentially hostile local shell users isn't a particularly common threat for webapps, but I could have sworn I had the umask stuff set appropriately. Guess I was wrong (or some default changed somewhere when I wasn't looking..)

A quick check of my image repository shows an 0600 or 0700 mask on the directories but 0644 on the files. Stuff in /tmp seems to be 0711 or 0755 or 0644.

Thanks for pointing this out; I'll see if I can easily fix this in one place or if I have to fix things everywhere a umask is handled..

pizza commented on 2010-08-10 13:27

Apparently using umask() in a multithreaded PHP server environment isn't quite kosher, as other threads share -- and can change -- the umask setting.

Do you have any other PHP stuff running on the same server?

kaz commented on 2010-08-11 02:31

Yes I do have other PHP stuff, like for instance the RoundCube webmail.


Available keyboard shortcuts


Task Details

Task Editing