-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nextcloud: restrict web server support to nginx; stop sharing nginx user/group; improve setup service #93584
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some initial thoughts I had which might be a starting point for further discussion.
default = "nextcloud"; | ||
description = "User of the nextcloud service"; | ||
}; | ||
group = mkOption { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another possibility here would be to keep running nextcloud
services (including php-fpm
) as a non web server user (like the current nextcloud
user) and instead add the nextcloud
group to your web servers extraGroups
option, like so:
mkIf cfg.nginx.enable {
users.users.nginx.extraGroups = [ cfg.group ]; # in other words "nextcloud"
}
The reason for this is that the nginx
user (and group) likely has access to very sensitive files, such as certificates. If nginx
can read nextcloud
files (which you want) that is much less of a risk than having nextcloud
able to read nginx
files - a serious security concern. This obviously requires that your nextcloud
files are g+r
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a good idea. The files created by nextcloud seem to be g+r
, so this shouldn't be an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder how to best change the user/group of nextcloud without breaking existing installations. It would require a one time service run as root which changes the ownership. And I would need to have some state file to save that this setup has been completed.
Alternatively I could leave the default user.group to be nginx if system.stateVersion <= 20.03
, but i don't really like that approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forget about it. Since it looks like the user will still be nextcloud
, only the group needs to be changed from nginx
to nextcloud
which is easy to do in the current setup. Also no state needs to be stored.
Did anyone of you test what happens when deploying this configuration to an existing Nextcloud instance? Also, what's supposed to happen if |
- remove optons cfg.user, cfg.groups - add option `serverUser` which is required when not using nginx - add `serverUser` to nextcloud group - set user/group to "nextcloud" for nextcloud services - make setup-service non-root
please check 6ee3004.
Did not yet implement a solution for fixing group ownership of files for existing installations. Your suggestions are welcome. |
@DavHau for context how are you trying to run |
Sorry my description of what I changed was not very precise. All nextcloud services now use the user and group "nextcloud" (hard-coded). The web server user must therefore be part of the the nextcloud group. The webserver user can be configured via
An example configuration using nginx would be: { pkgs, ... }:
{
networking.firewall.allowedTCPPorts = [80];
services.nextcloud = {
enable = true;
hostName = "10.233.1.2";
config.adminpass = "test";
package = pkgs.nextcloud19;
};
} A configuration for an alternative webserver could look like this: { pkgs, ... }:
{
networking.firewall.allowedTCPPorts = [80];
services.nextcloud = {
enable = true;
hostName = "10.233.1.2";
config.adminpass = "test";
package = pkgs.nextcloud19;
# disable nginx and set serverUser
nginx.enable = false;
serverUser = "caddy";
# caddy config
...
};
} |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good 👍
Co-authored-by: Aaron Andersen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation seems fine: nginx
is in most of the services in our tree that serve HTTP the default choice and now it's possible here to opt-out by disabling it.
Also did a brief test of the altered functionality and it appears fine to me.
However there are a few things I'd like to get resolved before merging this:
-
We should mention this in our release-notes. When having a big library in your nextcloud, the
chown
will take some time, so admins should be aware of this before deploying the new config. -
Removed options must be documented with
mkRemovedOptionModule
. -
The nextcloud-specific tests don't evaluate because of the removed
nginx.enable
option.
753d8a9
to
8516f4f
Compare
Things done:
I don't think this will be necessary. Up until this point the setup service always did a chown an all nextcloud files on each startup. Therefore the new implementation doesn't bring any performance drawbacks compared to the old one. |
8516f4f
to
ca916e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, LGTM 👍 I have not tested and don't use this module, though, so need someone like @Ma27 to approve as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
- Did anyone test this with live data yet? I just checked whether the "migration" to the new config works fine in a temporary VM network.
- We should mention this in the release notes. The rollout of the new config can take quite long due to the recursive
chgrp
.
This broke then manual: log. Plz fix, kthxbye. Or wait for a 10-12h, then I'll probably get around to it myself. |
Follow-up for NixOS#93584[1]. This change adds a simple example how to use `Nextcloud` with `httpd`. [1] NixOS#93584 (comment)
Follow-up for NixOS#93584[1]. This change adds a simple example how to use `Nextcloud` with `httpd`. [1] NixOS#93584 (comment)
The web server for the nextcloud module is now restricted to nginx. For more information, see: NixOS/nixpkgs#93584
Hello, I have read the manual on how to use a different webserver for nextcloud. Thank you in advance for the clarification :) |
Things done
(This description is heavily outdated. Plans changed a lot due to the discussions. See below)
nginx
and an error is raised if group is set manually.mkdir
+chown
nowinstall
is used to setup the directories.This has the disadvantage that the group of nextcloud cannot be changed anymore on an existing installation without having to fix the ownership of files manually. But it think
chown
ing all files on every single startup is bad since it's a very intense operation and can take very long depending on the amount of files stored. Also thechown
operation itself might not be allowed depending on the filesystem. I for example use a sshfs mount for my nextcloud files where this failsfixes #69261
fixes #48881
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)