I think the idea of putting training wheels on superuser is pretty
hopeless; there's too many ways in which that allows escape to the OS,
and even if we could close them all, the resulting system would be
very much less useful than today.
I definitely agree with the sentiment, but I also think that allowing superuser to trivially run arbitrary shell commands is not needed for basically any of our users. I can see how it's somewhat useful for development, but the biggest benefactor of this command are by far attackers. OSes also don't ship with tools installed that are only useful for attackers, so why should we?
One idea would be to disallow FROM PROGRAM when connecting over the network instead of a Unix socket. Because for development unix sockets should be fine. Network FROM PROGRAM seems to really only serve attackers.
The right thing is to move people away from using superuser so much.
Compare this to the Unix root situation. The OS guys have not tried
to cripple root, but they have started to offer setups where there's
no way to log in as root. And there's protections like sshd not
allowing login as root (with its default settings anyway). I like
Jacob's idea of requiring some external input, eg a config file
change, before you could become superuser. I don't necessarily
want to be forced to operate in that world, but we could make it
easier to set up installations that have such restrictions.
Agreed that that's much better. I think we're still not at the point where we can do this by default without basically everyone needing to turn it on. But what we maybe can do, is only allow UNIX socket logins to super user by default (maybe even only peer authentication). Requiring people to set a dangerous_superuser_over_network GUC (in addition to configuring hba.
