Changing ownership of /etc/ and directories under it like that sounds fine in theory but in practice breaks in many ways.

I did some extensive testing of this some years ago (on Debian/Ubuntu) and many system services and tools expect/require these directories to have specific ownership and permissions.

In the context I was experimenting with it was pretty simple too - renaming the UID 0 'root' account to some other name. That revealed that many tools actually test for "root" (the string) not uid == 0.

As I dug into the code of those tools I found many would also check and insist on particular ownership and modes on the directories and files.

I forget which one really annoyed me, but 'all' I wanted to do was allow members of group 'adm' to read/write into a particular sub-directory of /etc/ but the service would bail out if the directory wasn't owned by "root":"root" (or 0:0) and had 0700 permissions which is a pain when wanting to run services unprivileged and using 'setcap' to enable capabilities without starting as UID 0 and dropping privileges.

An alternate approach is to set the sysctl for this:

    net.ipv4.ip_unprivileged_port_start=80

Or whatever port you want unprivileged to start at. If you set it to 0 it means any user can bind to any port < 1024.

Ref: https://www.kernel.org/doc/htmldd/latest/networking/ip-sysct...

> Have an administrator `setcap cap_net_bind_service=+ep /your/binary/here` and you can use any port you want.

And remember to do it again every time the binary is updated :/

> chown /etc to nobody:wheel and

Bad idea! nobody is supposed to own no files at all. You run untrusted services (or untrusted users without account; something like anonymous FTP access) as nobody. This would potentially allow the least trusted entity to change your configs.

Apart from that. Since root can read any file anyways there is no reason to change the owner. And some programs may complain if the configuration is not owned by root.

Yes, having to always explicitly specify all the fine grained capabilities a process might need is a pain, too.

Having a process request its required capabilities and sudo displaying that list to the user, who can agree to sudo giving giving them only those capabilities would be good.