Skip to main content


Implications of access by the user www-data to all friendica folders


@Friendica Support

Hi there,
the friendica helpers page describes the installation process of friendica as follows:

/help/Install: wrote:

The Linux commands to clone the repository into a directory "mywebsite" would be
git clone https://github.com/friendica/friendica.git -b stable mywebsite
cd mywebsite

bin/composer.phar install --no-dev

Make sure the folder view/smarty3 exists and is writable by the webserver user, in this case www-data

mkdir -p view/smarty3
chown www-data:www-data view/smarty3
chmod 775 view/smarty3

Get the addons by going into your website folder.

cd mywebsite

Clone the addon repository (separately):

git clone https://github.com/friendica/friendica-addons.git -b stable addon


askubuntu.com: wrote:

What is the www-data user?
https://askubuntu.com/questions/873839/what-is-the-www-data-user
The web server has to be run under a specific user. That user must exist.

If it were run under root, then all the files would have to be accessible by root and the user would need to be root to access the files. With root being the owner, a compromised web server would have access to your entire system. By specifying a specific ID a compromised web server would only have full access to its files and not the entire server.

I guess this observation goes both ways, a compromised friendica instalation get's access to all the friendica folders if I choose to first create/activate the www-data user, than create the friendica installation folder structure, than git clone friendica, than create the smarty3 folder and ultimately do the git clone of the addon folder as described here:
https://tupambae.org/display/0ac89072-2065-5da2-9124-8b5839853793
The order in which the creation of www-data related folders in the above case is described makes all folders and files in the friendica directory belong to www-data.
In the friendica help description first comes the git-clone, than the the smarty3 folder part than the addon git-clone. Actually I guess that last part would make the addon folder belong to www-data too if I run one command after another. Is that intended?

I wonder if this could have some kind of security implications.
I guess www-data is somehow the friendica site and has permissions to do "what ever it wants" (-> "writable by the webserver user") with all the folders in the friendica directories if it's the owner of them.


@TupambAdmin [stable]

in reply to utopiArte

@utopiArte For a Friendica node to work properly, the web server user (here www-data) needs to have read access to the whole Friendica folder structure and write access to a few important places, including the smarty3 cache folder. The simplest way to achieve this is to grant ownership to the whole Friendica file tree to www-data.

The security implication is that if someone ever gains unauthorized access to www-data, they can indeed do "whatever they want" with your Friendica install, including deleting files, adding malware to Friendica pages, access the whole Friendica database including the user list, the private post and messages.

And if you host multiple websites on the same server, they can also access and tamper with those if their file trees are owned by the same user.

It's a big "if" though, as on Debian-based distribution like Ubuntu, the www-data user doesn't have shell access, meaning that you can't open a remote shell using this user. Any unauthorized access has to go through the actual hosted applications. For example WordPress is a popular unauthorized access vector for malicious actors because it's so popular and people don't always update their software timely.

I don't think Friendica is very secure, but it is a low-profile target and we do act quickly when we receive security reports, even releasing hot fix versions when the scheduled release date is a little to far.

You can make your install marginally more secure by only giving access to the file tree through group permissions and only giving read/traverse rights by default, granting write rights only for the specific locations that need it. This way, in case of a malicious access, it will prevent attackers from inserting malicious code in your Friendica node pages, but that's about it.

in reply to Hypolite Petovan

> granting write rights only for the specific locations that need it

What folders would that be?

What I have seen so far that would be:
/storage
/view/smarty3
and
/config
but only while installing local.config.php

Something I don't understand is why I do have a few folders in:
/view/smarty/compiled
that belong to the user root.
How is that possible?
How can friendica create folders as and/or for root?

What should I expect to happen if I just delete those folders, or even delete the complete /compiled folder. I guess friendica would start from there to create the folder compiled and subfolders as needed?

I ask because there are those subdirectories belonging strangely to root and one of my issues is that when I switch to the theme FRIO I have no access anymore to the settings of that respective profile, not even to change back to VIER. That renders that profile nearly useless and I'm trying to get around that problem.

in reply to utopiArte

@utopiArte That's a good list of exceptions.

Regarding the root-owned folders, it would prevent www-data from reading the cached template files and subsequently display the pages that uses the specific templates in this folder.

You should restore recursive www-data ownership to this or these folders. Please let me know if you need an example of a command line to do so.

in reply to Hypolite Petovan

I guess to just change all the folders/subfolders and files regardless of their ownership that would be:

rootname@VPShosting:/var/www/html/view/smarty3/# chown -R www-data:www-data compiled

in reply to Hypolite Petovan

Just checked the settings page of one of the profiles in question and yes, that fixed it.
thx
👍

(again, how could this possibly happen, shouldn't we look for some bug somewhere or do we just assume some quantum entanglement?)

in reply to utopiArte

result:

What I don't get is where these ownership settings came from.
They were not even from a specific day or had anything specific in common:
https://tupambae.org/display/0ac89072-1865-63c1-9da8-4ab292183263


Just checked all the 13 of 220 folders that were created as belonging to user and group root and that I consider shouldn't exist as owned by root i the folder /smarty3.

In general terms speaking I couldn't find a common property.

They refer to posts or replies by three different users.

Most refer to one specific post.

Two create a page:
Not Found
The requested item doesn't exist or has been deleted.
Request: XYZ

All were created with the theme VIER.


in reply to utopiArte

@utopiArte @Hypolite Petovan this is most likely just some goof while doing something minor that you wouldn't have even connected to this at the time.

No amount of proficiency and watchfulness eliminates user error, it just becomes increasingly obscure.

in reply to Shiri Bailem

Even tho there have been some trouble while setting up this installation what calls my attention ist that those folders had kinda random different dates of creation:

drwxr-xr-x 3 root root 4096 Nov 12 04:35 00
drwxr-xr-x 4 root root 4096 Nov 16 02:10 30
drwxr-xr-x 3 root root 4096 Nov 17 19:35 3e
drwxr-xr-x 3 root root 4096 Nov 11 01:57 49
drwxr-xr-x 3 root root 4096 Nov 16 22:25 4e
drwxr-xr-x 3 root root 4096 Nov 11 01:55 59
drwxr-xr-x 3 root root 4096 Nov 14 11:10 90
drwxr-xr-x 3 root root 4096 Nov 21 22:50 a3
drwxr-xr-x 3 root root 4096 Nov 23 00:45 a4
drwxr-xr-x 4 root root 4096 Nov 23 19:15 ae
drwxr-xr-x 3 root root 4096 Nov 23 20:35 b4
drwxr-xr-x 3 root root 4096 Nov 16 00:53 bf
drwxr-xr-x 3 root root 4096 Nov 14 11:10 e2
in reply to utopiArte

@utopiArte @Shiri Bailem Cache folders are created as needed. Since they are based on the 2 first or 2 next characters in the hash of the cached template, their distribution is supposed to be random. Not every page gets called every time, and then when you update your node some templates change and their hash with them.
in reply to Hypolite Petovan

Like to say this started with one folder being owned by root and from there others were created with the same ownership?
in reply to utopiArte

@utopiArte @Hypolite Petovan it might be helpful to note: only root can create folders owned by anyone else, so those folders had to be created from friendica or some part of it running as root at the time they were created, this is why I said it was likely user error
in reply to Shiri Bailem

That's what astonishes me.

My access is only via console SSH to the VPS and that shouldn't create any kind of cross implications with the firefox webbrowser that accesses the friendica installation.

Also apparently the installation itself was created the 8th of November, the first folder apparently the 11th of November so there was no relation to that.

If friendica is able to create a folder and files as root that's kinda scary isn't it?

in reply to utopiArte

@utopiArte @Hypolite Petovan it's not able to, and if it was it would be considered a massive linux security bug rather than a friendica bug.

SSH and VPS mean nothing for this situation, you likely just ran something with sudo at some point.

in reply to Hypolite Petovan

> That's a good list of exceptions.

In theory I could there for run the following commands to set all folders except /storage and /view/smarty3 to root:

set ownership of everything recursively to root:
rootname@VPShosting:/var/www/# chown -R root:root html

set ownership of storage and smarty3 recursively to www-data:
rootname@VPShosting:/var/www/html/# chown -R www-data:www-data storage
rootname@VPShosting:/var/www/html/view/# chown -R www-data:www-data smarty3

The change of ownership wouldn't affect the specific read/write permissions of files and folders and www-data would have only access to the folders needed.

right?

in reply to utopiArte

@utopiArte Indeed, it is separate. Please be on the lookout in your log for message like "Can't open file: Access denied" in case we missed a crucial place.
in reply to Hypolite Petovan

I ended up doing the following:

First I created a backup folder of the existing html folder and subdirectories:

root@VPShosting:/var/www# cp -r html html_01.bak

By default that created a copy with all files and folders owned by root.

Than I changed the ownership of storage and smarty3 to www-data:

root@VPShosting:/var/www/html_01.bak# chown -R www-data:www-data storage

Screen of the new user and group owner ship setting of the /html folder

root@VPShosting:/var/www/html_01.bak/view# chown -R www-data:www-data smarty3

Screen of the new user and group owner ship setting of the /view folder

Once everything looked "fine" I moved the existing html folder to a new name.

root@VPShosting:/var/www# mv html html_www-data_old

By moving [mv] instead of copying [cp] the ownership of files and folders aren't affected. Than I moved the copy with the new ownership settings into place:

root@VPShosting:/var/www# mv html_01.bak html

Well see how this setup behaves.
In any case I'll have the old version at hand to change to it if necessary.

in reply to utopiArte

@utopiArte security implications are minor, mostly because they can only edit the thing they've already hacked into.

But if that's a particular concern, you should be able to make the entire directory read-only as I don't believe friendica edits any of those files after initial setup (since all the edits are in database, or a separate storage folder if you're using the folder storage backend)

The writable in your quoted instructions is for the setup process while logged in under that user, so of course it'll need write to be able to download files and install them in the webserver directory. But there's no indication that it's needing write past that.