The comment above describes why it needs RW permissions. Are you asking us to look into alternative manners of handling this so it only needs read permissions, or are you looking for suggestions on how you can handle this differently?

I'm also pretty sure ZNC writes to the config every time a change is made (i.e. new user created, network added), so it definitely needs write permission.

Are you asking us to look into alternative manners of handling this so it only needs read permissions, or are you looking for suggestions on how you can handle this differently?

Either one would be fine by me, honestly. If there's a workaround that's available in the current version of ZNC I'd love to know about it.

Off the top of my head, I imagine you could create a znc.conf.lock file in the same directory as the config file to prevent two processes from using the same config file. Also, if the intent of the file lock is to prevent another process from modifying the config file, that intent is kinda moot if the file is set to read-only (chmod 400) in the first place. Correct me if I'm wrong.

I'm also pretty sure ZNC writes to the config every time a change is made (i.e. new user created, network added), so it definitely needs write permission.

This is true, but my plan is to not rely on this live-updating, instead I'd like to update my provisioning script (adding the user/network/module/whatever centrally), deploy the new config file and then /msg *status rehash. I'm guessing this is not the intent ZNC is designed around, but would still love if it was possible.

I don't know if ZNC has improved it over the years, but ZNC REHASH is supposedly very, very poorly written (and very unstable) and needs drastic improving.

Also, if the intent of the file lock is to prevent another process from modifying the config file

No. It's to prevent 2 ZNC processes to run together with the same config.

/znc rehash is supposed to go away at some point. But before that, I'd like to provide some alternative way to configure ZNC from external.

If you really want to manage config file by something else, restarting ZNC would be better than rehashing.

I'm also pretty sure ZNC writes to the config every time a change is made (i.e. new user created, network added)

Not quite. It does that if changes are made through webadmin. Also config is saved if user joins/part a channel when chansaver is loaded. Adding a network through *status doesn't write config itself.

Btw, znc.conf is only part of config. Modules store their settings in different places.

No. It's to prevent 2 ZNC processes to run together with the same config.

A separate lock file would still work to prevent this, then. Though if you were to theoretically change from a file lock to a lock file in a future version, that would make two differing versions of ZNC running on the same config possible.

I wasn't aware that rehash is being deprecated, I'll keep that in mind.

I don't currently have a problem with module config files, as they're being opened as read-only (at least .registry files).

I'm also trying to automate ZNC deployment with a configuration management tool, and would love to see a way to have ZNC not write its config file (and possibly keep users and networks in a different file than listeners and global config)