Arch Linux User Repository

@buzo @ChrisTX I see the cryptpad:http combinations for e.g. blob, however, the combination cryptpad:cryptpad and 0750 still does not allow read access for nginx for e.g. blob, so login is still prohibited in the current situation. At least on my machine, so please recheck. Thanks.

@buzo @ChrisTX This approach only works for me, if /var/lib/cryptpad is world readable. Otherwise I can not log in, aka I receive a "Permission denied" from nginx, when trying to read a block. Please check from your side.

Thanks ChrisTX – I've adjusted the permissions in the package as suggested.

Sorry, misleading description: groups http = http cryptpad and groups cryptpad = cryptpad. Gives http the theoretical access to some unneeded folders, but it is very simple. I do not think that this is a security issue, however, as soon as it is implemented in the package, I would follow the approach of choice there.

No, I mean, cryptpad shouldn't be part of http. That will allow it to read all files available to the web services, a permission which it doesn't need to have. Disregarding POSIX ACLs, the only 'proper' way of doing this is changing ownership to cryptpad:http and then setting the setgid bit on each of the subfolders nginx needs to access. I've done that right now in my own setup, but the package should do that.

@ChrisTX Yes, you are right. I replaced again the LTS version with nodejs, and it seems to work. It is the read access of http to the folders you mention. Currently, I added http to the group cryptpad, which then allows for it, and which I think is not part of the PKGBUILD right now, right?

@RoKoInfo No you're not wrong. The way cryptpad handles /blob and /block is by using try_files with nginx - so the server needs to be able to access those folders. Cryptpad should run fine with nodejs, and not require the LTS variant.

This is a bit of a mess, but the only reasonable solution I can see is to make the blob, block and datastore (that's for debugging purposes only tho) readable by nginx, i.e. http. Additionally, this will need the setgid bit on the folder. It's not necessary to make data or logs readable by nginx, they'll only be accessed by the nodejs service.

There's no real beautiful solution for cryptpad overall, as the app is supposed to be run in its source folder, and not really the way you'd package it.

Ok, I caught the trick: Use nodejs-lts-erbium instead of nodejs. So forget about the comments below.

If I change the directory rights of /var/lib/cryptpad to 770 and extend the service with UMask=0007, the error message changes to Can't remove login block, which seems to be again a 404 issue. The file is there, and the user http can delete it.

General question: Does it make sense to access /var/lib/cryptpad as http (nginx) instead of cryptpad (node)?

Unfortunately, I can not make this work. @buzo @ChrisTX Is this operational on your machines?

If I do a /checkup/, I get the message »Unable to create, retrieve, or remove encrypted credentials from the server.«, and a Can't read login block in the console, which seems to be reasonable to me, since the folder /var/lib/cryptpad is not accessible for nginx.

If I try a /login/, I get a 404 for the same reason, since nginx tries to access a URL .../block/... (although, however, the requested file is there).

How to fix this and leave the security measures (which I am not understanding fully) of Arch in place? Thank you in advance.