Web application package guidelines - problem with permissions

speed488 · 2024-05-23 22:14:58

I took a look at this page : Web application package guidelines as I am maintaining my own version of bookstack package (a web application) which is already available on the AUR, but I don't like how file uploads are handled its packaged form.
From bookstack's Filesystem Permissions page, you can see that 3 directories within the installation directory require to have write permissions. The installation directory, as per the guidelines, should be in /usr/share/webapps/{pkg_name}.

To accommodate the write permissions and keep the application in the recommended location, I decided to symlink the folders to their respective locations according to the guideline:

storage -> /var/lib/bookstack/storage
bootstrap/cache -> /var/cache/bookstack/storage
public/uploads -> /var/lib/bookstack/public

So far so good... But here comes the problem I'm facing. The guidelines state that a separate user should be created for the web application. I added a sysusers.d file to my package and a tmpfiles.d to properly set the permissions of the /var/lib and /var/cache folders.
I use nginx and php-fpm to serve my web app. Both use the http user by default. With my package, I have to add the bookstack group to the http user for it to be able to write to writable folders. However, doing so defies all purpose of creating a separate user in the 1st place.
Furthermore, the files created by php-fpm are owned by http and, on the next reboot, are changed to bookstack:bookstack by tmpfiles.d. But, the files are created originally with 644 permissions. So, after the user/group change, php-fpm cannot modify or delete the files anymore. I do not have any config in bookstack to force creating files with 664 permissions (unless I modify the code and issue a pull request on their github).

At this point, I am wondering if I am not dealing with this entire situation the wrong way. I'm wondering if I should not add a bookstack user and simply give r/w permissions to http:http for bookstack's writable folders. Am I missing something?

Thanks

Trilby · 2024-05-23 23:29:01

speed488 wrote:

The guidelines state that a separate user should be created for the web application...
Both [nginx and php-fpm] use the http user by default.

I've not used Bookstack myself, but if it is indeed it's own web application, that web app itself would run as it's own user on the server and nginx would serve as a reverse proxy for that web app (forwarding traffic to it and directing output from it) - nginx and php-fpm would not touch anything in the web-app's directory structure themselves (nginx would just send/receive data through a socket to the webapp, and the webapp would do any filesystem reads/writes).

Alternatively, if it is not an executable webapp in and of itself, but is rather a php script, then there would be no reason at all for it to have it's own user.

The instructions I have found make it sound far more like the second case.

Last edited by Trilby (2024-05-23 23:32:27)

speed488 · 2024-05-24 12:22:06

Thanks for the reply.

Trilby wrote:

Alternatively, if it is not an executable webapp in and of itself, but is rather a php script, then there would be no reason at all for it to have it's own user.

That is correct; it is a PHP web application that requires a web server and PHP-fpm to work. It is not a standalone application that listens to HTTP requests.

On the same subject, I have recently adopted an orphaned AUR package mantisbt. MantisBT is very similar to Bookstack as it is a PHP web application that (optionally) requires write access to disk.
The former maintainer added the mantisbt user/group to the package at some point to follow (I guess) the web applications guidelines. This is what lead me to believe that I had to do the same with Bookstack.

Given that you mention that there is no reason to create it's own user for web applications that requires an external HTTP server and interpreter, I have a few questions.

Should I update the web application package guidelines pages?
Should I revert the mantisbt user/group from the package I'm now maintaining?
As for the /var/{lib, cache}/{pkg_name} folders, should I simply set them to http/http in the package creation itself? I'm afraid that if I use tmpfiles.d, it will constantly change file/folder ownership on every reboot and potentially alter a user's custom configuration.

Thanks

Trilby · 2024-05-24 12:30:59

speed488 wrote:

Should I update the web application package guidelines pages?

No. That advice is valid for actual web applications. You are not packaging a web application. Certainly there is inconsistency in the terminology here that leads to confusion, but the "Web applications packaging guidelines" apply to a different category of things than what you are packaging. It's not relevant. And it's not wrong. The web application guidelines are for web applications that run their own executable code, formerly cgi was common, now it's mostly wsgi including a lot of python apps. This is not what you are packaging. If that page needs any update perhaps some clarification on the scope / applicability could be called for.

Theoretically, a php script based web content could include it's own executable php interpreter. In that case it would be a proper web app and that secondary instance of php would run as it's own user (which could then be reverse-proxied by nginx to go allow access to the outside world). But that's also not being done here. The BookStack content is interpreted by the system-installed php-fpm. So it's really just a script / content, not it's own app.

speed448 wrote:

Should I revert the mantisbt user/group from the package I'm now maintaining?

If that is also just php/html content and not it's own executable then I'd question why it should have it's own user. I can't rule out other reasons for having it's own user though. Further, does it work? If it ain't broke...

speed488 wrote:

As for the /var/{lib, cache}/{pkg_name} folders, should I simply set them to http/http in the package creation itself?

I'm not sure I can answer that - it would seem reasonable to me to do so, but I'm not even sure why your doing all the symlinking to /var in the first place. This also seems to come from applying packaging standards that should not apply to this package in the first place.

Last edited by Trilby (2024-05-24 12:54:32)

speed488 · 2024-05-24 13:18:58

Trilby wrote:

I'm not even sure why your doing all the symlinking to /var in the first place.

For two reasons:

systemd by default prevents services to write to /usr. You have to explicitly allow it in the service file (or via override). In this case, php-fpm service.
It is not clean to have application data written in /usr. This should be reserved to package's RO data only.

Trilby · 2024-05-24 13:19:59

Thanks - those are indeed good reasons. Keep those symlinks.

speed488 · 2024-05-24 13:28:51

Trilby wrote:

now it's mostly wsgi including a lot of python apps.

You hit the nail on the head with this. MantisBT has a uwsgi config file in the package if ever you wanted to host the web app directly via UWSGI (not using nginx/apache + PHP-fpm). This would explain why the former maintainer created the user/group.

Everything makes sense. Thanks for all the clarifications!

Arch Linux

#1 2024-05-23 22:14:58

Web application package guidelines - problem with permissions

#2 2024-05-23 23:29:01

Re: Web application package guidelines - problem with permissions

#3 2024-05-24 12:22:06

Re: Web application package guidelines - problem with permissions

#4 2024-05-24 12:30:59

Re: Web application package guidelines - problem with permissions

#5 2024-05-24 13:18:58

Re: Web application package guidelines - problem with permissions

#6 2024-05-24 13:19:59

Re: Web application package guidelines - problem with permissions

#7 2024-05-24 13:28:51

Re: Web application package guidelines - problem with permissions

Board footer