Owncloud only needs to be able to write in the data directory (and maybe 3rdparty), having all its files and directories owned by www:www is pretty bad, from a security point of view.
If users plan to run owncloud as a nonstandard user, they can override OWNCLOUD_USER and OWNCLOUD_GROUP in their custom build environment.
You're missing the point, most of the files MUST be owned by root, not by www, with only a couple of directory where owncloud needs to write owned by www.
owncloud also needs to be able to write to config/config.php
Does r393684 address your concerns? Thanks.
still feels dangerous to have the app directory writable, but seems better :-)
I think choice whether a running application can modify its own code can be a security advantage or a flaw. I agree in an ideal circumstance, an application should not be able to modify itself, it should have one dedicated user for execution and another file owner for executable files. The problem is this conflicts with other security mechanisms which try to use a different runtime user for individual websites (avoiding www:www) if that mechanism expects to run php files as their file owner and that file owner is root. Not all environments have multiple users available. One way or another, an attacker can probably find a way to cause remote code execution and the integrity of owncloud may not be the biggest security concern on that server. If I was sufficiently paranoid about owncloud, I would have put it on a dedicated instance already. *Optionally* changing the owner of owncloud files allows at compile time allows it to fit in environments where compartmentalization is more important than individual web app integrity. Excluding this option from the port simply rules out one security mechanism out of many. If support for it is intentionally removed, it should be completely removed and a stance on the change noted in the change logs so admins can decide how to handle the change. Going back and forth on the support of this option makes me even more hesitant to upgrade promptly when new versions are available. I greatly appreciate having the port handle upgrades because it is usually trivial enough that I will actually do it. Please, I urge "Tools, not policy". As an aside, not speaking of owncloud but some web applications have the ability to automatically upgrade themselves which is a bit terrifying but can be an overall win in environments where that will occur before an admin has a chance to do it. That would not be appropriate for ports but just pointing out not all webservers have every single web application maintained by root. Thanks for your consideration. I am just trying to nail down a mode that will work with what mechanisms I have. I don't yet have the means to build isolated environments for every web service since they will number in the tens or hundreds.
I'll just keep my locally modified pkg-plist for this port until we can change our web user model to suit the port better. This bug can be closed.
@kevlo can you close this bug, it was fixed
The problem was fixed.