Tor always overwrites onion service hostname file, but should leave it alone if it shouldn't change
If you start your Tor with an onion service, it will make the appropriate files in your onion service directory, e.g.
$ ls -la hidden_service total 32 drwx------ 3 arma arma 4096 Jul 24 05:14 . drwxrwxrwt 21 root root 12288 Jul 24 05:11 .. drwx------ 2 arma arma 4096 Jul 24 05:11 authorized_clients -rw------- 1 arma arma 63 Jul 24 05:14 hostname -rw------- 1 arma arma 64 Jul 16 00:11 hs_ed25519_public_key -rw------- 1 arma arma 96 Jul 16 00:11 hs_ed25519_secret_key
but if you then set the directory to read-only, Tor will fail to start, complaining
Jul 24 05:16:38.104 [warn] Couldn't open "/tmp/hidden_service//hostname.tmp" (/tmp/hidden_service//hostname) for writing: Permission denied Jul 24 05:16:38.104 [warn] Could not write onion address to hostname file "/tmp/hidden_service//hostname" Jul 24 05:16:38.104 [warn] Error loading rendezvous service keys Jul 24 05:16:38.104 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.5.0-alpha-dev 5336ac26693cdba4)
Back in the day, I added some logic where it would first read the hostname file, and decide if it already has the correct content in it, and if it does, it would leave it alone (i.e. not try to write). It looks like either I misremembered doing that, or we lost that feature somewhere along the way.
If we resume doing that behavior, then people can set their onion service keys directory to be read-only, which will let them improve their opsec.
Bug reported by Jeff Moss on his Defcon onion.