nixos/transmission: improvements

[diniamo]

As per Transmission's documentation, the umask option should be a string.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[diniamo]

@ju1m could you help with this PR?

[ju1m]

@diniamo thanks for spotting this mistake, type = with types; either str int could be used for backward compatibility, and a warning can be added to issue a deprecation message of int for the next stable version (nixos-25.05) when typeOf cfg.settings.umask == "string".

[diniamo]

Does that mean I should remove the release note entry?

[ju1m]

@diniamo , sorry I did not notice you had already done all that work, what you did is better, thanks!

[ju1m]

LGTM

[diniamo]

@ju1m just to make sure: I changed serviceConfig.StateDirectoryMode to cfg.downloadDirPermissions as well. It's needed because other things can't access any subdirectories, if they can't access the parent directory. Alternatively, do you have a better solution?

[ju1m]

@ju1m just to make sure: I changed serviceConfig.StateDirectoryMode to cfg.downloadDirPermissions as well. It's needed because other things can't access any subdirectories, if they can't access the parent directory. Alternatively, do you have a better solution?

Right, no I would not change StateDirectoryMode= because the better way security-wise is to add users to services.transmission.group, or to set cfg.settings.download-dir & co. to some path where intended users have access to them (since they are bind-mounted into the RootDirectory= using BindPaths=, transmission will be able to access them).

Besides, if cfg.downloadDirPermissions is null (the default) then StateDirectoryMode= would default to 755 instead of the current 750 which would open transmission's state folder read-only to every users. Sure ${cfg.home}/${settingsDir}/settings.json is forced to 600, but yet, AFAICS it's not necessary to relax the 750, just use services.transmission.group, which is allowed read-only.

[ju1m]

Please keep 750 and let users add themselves to the transmission group.

[diniamo]

How do I add a user to multiple groups declaratively though?

Edit: seems like removing the downloadDirPermissions option worked. Although what happens if you set it to null is not documented.

[ju1m]

How do I add a user to multiple groups declaratively though?

users.users."diniamo".extraGroups = [ config.transmission.group ];

Or:

users.groups.${config.transmission.group}.members = [ "diniamo" ];

[diniamo]

And do you know why setting downloadDirPermissions to null makes it 755? I'll add a note about that to the description.

[ju1m]

And do you know why setting downloadDirPermissions to null makes it 755? I'll add a note about that to the description.

Yes, I explained it in my previous message. But please do not use StateDirectoryMode = cfg.downloadDirPermissions; there's no need to relax 750 since user groups or bind-mounts are a common and more secure way to give access to directories.

[diniamo]

How is this?

[ju1m]

Hmm, I think you've misunderstood what I tried to say previously, when I wrote:

Besides, if cfg.downloadDirPermissions is null (the default) then StateDirectoryMode= would default to 755 instead of the current 750 which would open transmission's state folder read-only to every users.

I was describing what would happen if we were to use StateDirectoryMode = cfg.downloadDirPermissions; but that's no longer the case, so downloadDirPermissions == null remains a no-op.

Indeed, the description only documents the If not null, case, but adding users to config.transmission.group is unrelated to that option being null or not, it's related to StateDirectoryMode == "750".

[diniamo]

Then that option is very misleading. If I set it to 755, then I expect other users to be able to read the download directories, which is not the case. This is very unintuitive, and the option descriptions don't mention this anywhere. It took a long while before I figured out what was going on.

It would be nice if we could avoid wasting others' time. What do you suggest?

[ju1m]

IMHO, downloadDirPermissions is a quirk that should not even exist in the first place, since adding users to services.transmission.group is both more secure and more idiomatic.

Yet this option lingers and we have to deal with it, I would suggest to improve its description by explaining the two main ways to give access to the directories that I explained previously:

1. the better way security-wise is to add users to services.transmission.group,
2. or to set cfg.settings.download-dir & co. to some path where intended users have access to them [and use settings.umask = "002" and downloadDirPermissions = "755"]

[diniamo]

How is this?

I did some minimal testing in a VM, and it seems to be working fine.

[Aleksanaa]

We have to wait until after NixOS 24.11 as this is a breaking change and not a trivial fix.

[diniamo]

I don't get it. Why do we have to wait for 24.11?

[Aleksanaa]

Because breaking changes are blocked in this period to prepare for the next release. See #339153

[diniamo]

@ju1m it looks like I didn't do enough research: transmission 3 (which is the default for the module) still uses the old way of configuring umask (decimal number), while transmission 4 uses the new way (octal number as a string). Should I update the default package as well, or?

[ambroisie]

@diniamo should probably be using type = with lib.types; either str int; (which would make it a non-breaking change) to accommodate both versions.

EDIT: maybe adjusting the default to be 2 or "002" depending of the version of cfg.package would be good too.

[diniamo]

I was thinking of something like that as well. Thnaks for that suggestion, I'll implement it.

[ju1m]

@ju1m it looks like I didn't do enough research: transmission 3 (which is the default for the module) still uses the old way of configuring umask (decimal number), while transmission 4 uses the new way (octal number as a string). Should I update the default package as well, or?

@diniamo, chances are that nixos-25.05 (first NixOS stable release on which this PR will land) may indeed switch to transmission_4 as default for services.transmission, which is currently blocked to transmission_3 for nixos-24.11:

nixpkgs/nixos/doc/manual/release-notes/rl-2411.section.md

Lines 210 to 212 in b166978

	- `transmission` package has been aliased with a `trace` warning to `transmission_3`. Since [Transmission 4 has been released last year](https://github.com/transmission/transmission/releases/tag/4.0.0), and Transmission 3 will eventually go away, it was decided perform this warning alias to make people aware of the new version. The `services.transmission.package` defaults to `transmission_3` as well because the upgrade can cause data loss in certain specific usage patterns (examples: [#5153](https://github.com/transmission/transmission/issues/5153), [#6796](https://github.com/transmission/transmission/issues/6796)). Please make sure to back up to your data directory per your usage:
	- `transmission-gtk`: `~/.config/transmission`
	- `transmission-daemon` using NixOS module: `${config.services.transmission.home}/.config/transmission-daemon` (defaults to `/var/lib/transmission/.config/transmission-daemon`)

But that would have to be discussed with people involved in #258058

[diniamo]

In that case, I'll leave updating the default to them, and this should be fine.

[diniamo]

@Aleksanaa this is no longer a breaking change.

[l0b0]

Thanks!

[diniamo]

@l0b0 is there anything else to do?

[l0b0]

@l0b0 is there anything else to do?

Not as far as I'm concerned - I already accepted. I don't have merge rights though.

[diniamo]

Oh huh, I thought you did.

[diniamo]

Thanks!