Feature request: Declarative configuration of triggers via config file

[inanna-malick]

I would like to be able to declaratively specify watchman triggers in the watchman config file, for triggers that I wish to be active for the lifetime of the watchman service (example: watching some directory and running a script for each torrent file added to it, to automate downloading linux distros). Currently, there is no way to do so, but since both the watchman config file and the watchman state file are stored as json, it should be fairly simple to include a config file field such as additional_triggers that uses the same trigger format as in the state file to allow for declarative configuration of triggers.

[wez]

We classify this a "wontfix" for security reasons; consider that someone has a git repo with a .watchmanconfig with an embedded trigger that performs rm -rf /. As soon as your fsmonitor enabled git or mercurial sets up the watch for that repo, you have a problem! This is the same class of issue as implicitly setting up eg: local git repo hooks specified by the server at clone time.

Our recommendation is that you initiate the trigger from a script that is explicitly run by the user; this gives them an opportunity to inspect what actions it may take before they occur, and crucially: that the potentially dangerous trigger doesn't happen implicitly as a side effect of looking at the watched directory structure.

[inanna-malick]

Thanks for the quick reply! How would you recommend setting up triggers for a user with shell set to nologin managed by nixos? I'm currently looking at setting up a state file via some systemd unit run before the watchman service.

[wez]

What's the goal/background of making the user nologin?
The trigger feature will allow arbitrary commands to be run by the watchman server process, so if this is intended to be run in a totally locked down environment it may be difficult to guarantee that there is no escaping that restriction.

Ignoring that for now: if you own the system and know the user(s) for which you're setting this up ahead of time, then you could run the trigger setup ahead of time using su/sudo or some other way to run the watchman cli as the appropriate user. Be careful with the environment: watchman will use that to figure out the socket path for user. The USER needs to be accurate.

[inanna-malick]

What's the goal/background of making the user nologin?

Background: this user is used to run a headless bittorrent client, with its home dir containing various configuration files and state for that client. nologin isn't intended to enforce any security constraints, it just seemed like a reasonable setting for such a user.

Watchman is run as a user service on that system, so this wouldn't provide any priv escalation to root.

(I am absolutely overengineering this for the fun of it, btw - part of the goal is to have full declarative specification of my home server, with known sha hashes of build inputs & etc)