Opensondage creation error

I’m having exactly the same issue stated here :

In english : You haven't filled in the first section of the poll.

In the logs i have several errors like this one :
2021/12/05 19:57:28 [error] 14949#14949: *752 FastCGI sent in stderr: "PHP message: PHP Warning: session_start(): open(/var/lib/php/sessions/sess_kn7c39mhk5l8gb5hebafltf90s, O_RDWR) failed: Permission denied (13) in /var/www/opensondage/app/inc/init.php on line 27PHP message: PHP Warning: session_start(): Failed to read session data: files (path: /var/lib/php//sessions) in /var/www/opensondage/app/inc/init.php on line 27PHP message: PHP Notice: Undefined index: markdown_editor_by_default in /var/www/opensondage/create_poll.php on line 295 while reading response header from upstream, client:, server:, request: "GET /date/create_poll.php?type=autre HTTP/2.0", upstream: "fastcgi://unix:/var//run/php/php7.3-fpm-opensondage.sock:", host: "", referrer: ""

Hello @Aristid,
and have you tried to fix the issue with :

sudo chown -v www-data:www-data /var/lib/php/sessions 

Yes i have and it did not do the trick…

I don’t remember how I did. I was probably lucky.
Maybe I used chown with user “opensondage” instead of www-data.
That’s what I wrote :
“Session files must belong to the opensondage user.”

What a fool, i copypasted without much understanding.

Solution is indeed : sudo chown -v opensondage:opensondage /var/lib/php/sessions

Uuuuuuh maybe it does fix opensondage, but setting opensondage as the sole owner of /var/lib/php/sessions is probably going to cause issues for other PHP apps that need access to this …

That’s what i never understand about permissions : how do you specify which user can access which folder if it can only have one owner and be in one group ? It often causes a brain meltdown so i avoid any interfering with permissions. Btw if anyone has a clear, understandable, applied guide or tutorial about that i’m in…

What would be the solution here ? chown this folder back to root/somegroup and put the opensondage user in this “somegroup” that has access to this folder ?

Yes, permissions are definitely not straightforward to understand. Key points to understand

  • they are pretty minimalistic, with only one owner, one groupowner, and “everybody else” = others.
  • But with that said, in like 95% cases, you don’t need much more than this minimalist system, because the user that need access to a file are pretty well identified. Usually there’s one process needing access - sometimes two, and maybe you want to give world-wide permissions for reading, and that’s it. So basically understanding what permissions to set requires to have a clear understanding of what user needs access to what
  • People usually forget that there’s two dimensions in the permission system : there’s the ownership, and there’s the “mod” part (i.e. the r/w/x). A classic example of this is people manually installing a web app (e.g. a wordpress), and whatever chmod they tried, they keep getting a permission denied error … so they end up doing a chmod 777 because that’s the only way they found it worked … Well, usually the issue is that the owner of the app’s files is root, and instead should be wordpress or www-app.
  • But ultimately there’s no magic recipe to magically guess what are the right permissions. Permissions are heavily related to security, which itself is complex because it requires to identify what user/process need and apply the “least privileged principle” (otherwise chown -R 777 your entire filesystem would solve the question once and for all ;)). In the context of apps in Yunohost, it all depends on how each app works. Some apps need to allow access to www-data (e.g. because nginx itself serves some static assets), sometime it’s not. Sometimes write permissions are needed because the app may allow file upload or self-edit its own config, sometime it’s just a purely static app. And all these questions apply to the install dir, the data dir, the log files, and that’s ignoring possible interactions between apps…
  • And all of this would be somewhat simple if on top there was the “advanced” permissions such as sticky bits, suid, guid :wink:

Anyway, I got carried away … Back to /var/lib/php/sessions : from what I see on my side, this folder should absolutely be owned by root:root … I also see that there’s the sticky bit (c.f. t at the end) which is too complex to explain in a forum thread

$ ls -ld /var/lib/php/sessions/
drwx-wx-wt 1 root root 0 Nov 27 03:09 /var/lib/php/sessions/

I don’t know why opensondage couldnt read the session file if it was supposed to … It could be that you’re missing the sticky bit for some reason, or it could be that you needed to reload php-fpm maybe …

1 Like

Thanks for the explanation, worth reading, good synthesis, i’ll come back to it !

I put back this directory to chown root:root as you recommended and now i am (always more) confused : opensondage is back into working order.

1 Like

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.