Usage of state.highstate wreaks havoc on user configurations

[tasket]

Qubes OS version (e.g., R3.2):

R3.2

Expected behavior:

Following config instructions which include execution of saltstack states should result only in the specific configuration task being acted upon.

Actual behavior:

User modifications across the system are suddenly and without warning re-configured!

Steps to reproduce the behavior:

Try the example salt configuration in https://www.qubes-os.org/doc/salt/
Enable state and execute qubesctl state.highstate

General notes:

There appear to be serious issues using saltstack in a PC context:

Changes users make after Qubes installation are often for functional or security goals. However, users will later encounter advice to enable features using qubesctl state.highstate which will have negative repercussions throughout the system!

For example, on my system a simple test of a new state/top pair resulted in:

• Hide-usb-from-dom0 was automatically enabled, which would prevent my AEM boot process from working.
• Grub attempted to install itself on a partition that doesn't exist.
• Creation of a new sys-net netVM. I had switched to a netVM with a different name, and this automatic re-addition was flagged to run on startup. This would prevent my normal network config from working.
• anon-whonix VM had its netvm setting changed back to a default value.

Recommendations:

• Disable states after they have been used to initially configure the system.
• Reconcile saltstack configuration with other Qubes configuration tools like anti-evil-maid-install.
• Provide methods of triggering only individual states, and change documentation to reflect this (possibly recommending the user disable the state after they are finished using it).

---

Related issues:

#1983

[marmarek]

Disable states after they have been used to initially configure the system.

Already done: #2173

Provide methods of triggering only individual states,

qubesctl state.sls name-of-sls-file should do in theory, but it does not allow to select target (other than --all, --templates etc).

[marmarek]

Disable states after they have been used to initially configure the system.

Already done: #2173

Provide methods of triggering only individual states,

qubesctl state.sls name-of-sls-file should do in theory, but it does not allow to select target (other than --all, --templates etc).

[h01ger]

On Sat, Apr 08, 2017 at 02:42:13AM -0700, Marek Marczykowski-Górecki wrote: > Disable states after they have been used to initially configure the system. Already done: #2173

the ticket confused me, on July 16 2016 you said it's too late for 3.2 and then three days later there's an updated package, which is later pushed to stable. So is #2173 fixed in 3.2 or not? (I havent started using Salt yet and #2173 doesnt make me want to try…)

…

-- cheers, Holger

[h01ger]

On Sat, Apr 08, 2017 at 02:42:13AM -0700, Marek Marczykowski-Górecki wrote: > Disable states after they have been used to initially configure the system. Already done: #2173

the ticket confused me, on July 16 2016 you said it's too late for 3.2 and then three days later there's an updated package, which is later pushed to stable. So is #2173 fixed in 3.2 or not? (I havent started using Salt yet and #2173 doesnt make me want to try…)

…

-- cheers, Holger

[marmarek]

The comment was about modifying salt modules, not leaving disabled after installation.

[marmarek]

The comment was about modifying salt modules, not leaving disabled after installation.

[tasket]

@marmarek Did I just not receive the update?

Also, there is documentation that instructs the user to enable top files, but doesn't instruct to disable them after use.

[tasket]

@marmarek Did I just not receive the update?

Also, there is documentation that instructs the user to enable top files, but doesn't instruct to disable them after use.