In your Markdown you haven't provided the alt text, but the title. See here: markdownguide.org/basic-syntax…

The alt text has to be between the two []. The text after the image link is the title. We don't support a separate title.

@Sascha 😎 🏴
Es ist nun etwas Platz zwischen den beiden Interaktionen.

github.com/friendica/friendica…

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

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

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.

New error message (of FRIO) about a folder created by the user root.

I haven't found the extensive conversation about this problem with @Hypolite Petovan yet but I'm quite sure that I changed all folders to ownership of user www-data before 28th of November of the smarty folder. Actually there was another conversation about ownership of folders and I changed all folders to be owned by root except storage and view that day on 02:45hs, the new folder owned by root at /view/smarty3/compiled/ like stated below was created on 3:50hs.

As for what I remember of all the conversations this shouldn't have happened.

<?php
/* Smarty version 4.3.1, created on 2023-11-28 03:50:02
  from '7cd2693513597460a71347ba02d3179c5e5ab822' */
/* @var Smarty_Internal_Template $_smarty_tpl */
if ($_smarty_tpl->_decodeProperties($_smarty_tpl, array (
  'version' => '4.3.1',
  'unifunc' => 'content_6565636a645732_50647552',
  'has_nocache_code' => false,
  'file_dependency' => 
  array (
  ),
  'includes' => 
  array (
  ),
),false)) {
function content_6565636a645732_50647552 (Smarty_Internal_Template $_smarty_tpl) {
?>[url=https://tupambae.org/profile/utopiarte]utopiArte[/url] replied to you on [url=https://tupambae.org/display/0ac89072-1065-6562-6405-8bb240314547]"bugreport - can't answer, like or reshare posts"[/url]<?p>

update:
this error happened again in this very post.

I had to separate the @ of the @ gimped@tupambae.org handle to be able to publish this to the helpers forum.

That gimped profile has become the administration profile because accidentally I used the same email address of the admin profile and actually locked the original admin profile out of the administration access by trying to change the email for gimped but being changed in that process to the admin profile, an error occurred twice already (profile change "on the fly" to a previous profile. That profile change error is an issue that was posted years ago as bug report on github and I experienced it several times already, once as mentioned now and once updating the profile pic of the tutorial forum page. That avatar is actually right now the one displayed in this utopiarte profile as I didn't changed it yet waiting to publish that bug research report as there is definitely something wrong with this avatar registry or location as it doesn't figure in any photo gallery.

Here the screen of this very same post that went out "restricted" and figures as only visible to gimped.