[fhars]

The real broken concept here is root. Why do I have to give a process the ability to do anything it wants with the system if I want it just to write to a file in /etc, or to bind to port 80?

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

[jeroenhd]

Port 80 doesn't need root access. Have an administrator `setcap cap_net_bind_service=+ep /your/binary/here` and you can use any port you want.

Files within /etc do, for security reasons, but there's no reason why you couldn't use user groups or other ACLs to secure those folders.

chown /etc to nobody:wheel and chmod it to g+rwx; users in group wheel will now be able to manage /etc. You've got to make sure you set your umask right if you do use sudo for /etc again, but that's also just part of your system configuration.

[iam-TJ]

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.

[BeefWellington]

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...

[Calzifer]

> 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.

[jeroenhd]

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

Depends on the way the file is replaced; if it's overwritten and not deleted + created, the flag should stick around I believe.

> 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.

You're right, should've used root:wheel rather than nobody:wheel. Oops...

[fhars]

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

[jeroenhd]

With Ubuntu's AppArmor you can run a lot of software without hassle because the ACLs come with the OS package.

[robertlagrant]

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.

[Beltalowda]

Being able to write to /etc/ is effectively just granting full access, since there's lots of things in there that can run code.

Doing fine-grained access is really hard; even without "root" you still have things like, say, "archive_command" in postgresql.conf which will allow running people to run arbitrary commands as the postgres user, and is that really what you want? There's lots of little things like that ranging from application configurations to crontabs to your init system.

[icare_1er]

Go ahead, send your commits to the Linux kernel then.