Make immutability into a config_var_t flag

changed milestone to %Tor: 0.4.3.x-final

Trac:
Parent Ticket: #29211 (moved)

added actualpoints::.2 component::core tor/tor milestone::Tor: 0.4.3.x-final network-team-roadmap-november owner::nickm parent::29211 priority::medium resolution::fixed reviewer::teor severity::normal status::closed type::task labels

Branch is ticket32344 with PR at https://github.com/torproject/tor/pull/1486.

Trac:
Status: assigned to needs_review
Reviewer: N/A to teor

Looks fine, but I don't know why some files are immutable, others are sandbox-immutable, and others can be changed at any time.

Should we have a flag for sandbox-immutable? (A sandbox-immutable flag would significantly simplify my relay refactor in #32213 (moved).)
Should all files be sandbox-immutable?
Should we also make HiddenServiceDir (sandbox-)immutable?
Should we also make Logs (sandbox-)immutable?
Should we be checking changes to options that require access to extra files, like onion authentication?

Trac:
Status: needs_review to needs_revision

In addition to possible sandbox-immutable options ,we need immutability depending on other things too. I'm hoping that those can wait a little till we have more of the refactoring done, and we can define the right interface for them.

Right now I'm torn between a few not-so-good designs:

Have filenames be sandbox-immutable, and nothing else?
Have a new flag for every kind of immutability we need?
Have a list of options for every kind of immutability we need?

Do you have any thoughts on the right design here?

How many kinds of immutability do we need?

Flags work well if we have a small number of simple kinds of immutability. But they still centralise some code.

We could let modules define an immutability function that gets run on every option? For example, a sandbox_config module would define an immutability function that prevents filenames, IP addresses, and other options changing. And if we have relay or dirauth immutability, then those modules could define those functions.

So to summarize the situation: I think that all files need to be sandbox-immutable.

I think that we'll come up with the right solution there when we do a refactoring for the sandbox code; this could be well handled with something based on #32339 (moved), which already looks at nearly all of the files, and which needs to start looking at all of the rest too. Currently my best guess is that constraints like this would want support for scanning all filename options, along with some way for reaching inside Log and so on.

If it's all right with you, could we take some version of this branch without covering other mutability invariants? I'd like to keep the scope small-ish here, to avoid delaying the key refactoring of #30866 (moved).

(Rationale for proceeding: I believe that this branch is a strict improvement over Tor's current behavior, doesn't introduce technical debt, and unblocks #30866 (moved). If you don't agree, we shouldn't proceed.)

Yes, I think we should go ahead, and make further changes in other tickets.

I'd like to merge #32213 (moved), #32339 (moved), and #32344 (moved) in that order, to minimise conflicts (if any). I'm just waiting for CI to pass on #32213 (moved).

Trac:
Status: needs_revision to merge_ready