Peter,
* Peter Eisentraut (peter_e@gmx.net) wrote:
> On 2/25/15 10:05 PM, Stephen Frost wrote:
> > Agreed, but I'd also like to get rid of any reason, beyond emergency
> > cases, for people to modify the catalog directly. There's a few places
> > which we aren't yet doing that, but I'd rather fix those cases than
> > encourage people to give out rights to modify them and end up making
> > things like:
> >
> > "UPDATE pg_database SET datallowconn = false where datname = 'xyz';"
> >
> > an accepted interface.
>
> I'm not sure those things are related.
Eh, I feel they are, but either way.
> Getting rid of the *reasons* for updating catalogs directly might be
> worthwhile, but I don't see why we need to install (or maintain) a
> special invisible permission trap for it. We have a permission system,
> and it works pretty well.
We have this "invisible permission trap" known as checking if you're a
superuser all over the place. I'm not against revisiting those cases
and considering using the GRANT permission system to manage access, but
that's certainly a larger project to work on. What I'm referring to
here are all the functions that check if you're a superuser, instead of
just revoking EXECUTE from public and letting the user manage the
permission.
> The Unix kernels don't have special traps for someone to modify
> /etc/shadow or similar directly. That file has appropriate permissions,
> and that's it. I think that works pretty well.
This isn't really /etc/shadow though, this is more like direct access to
the filesystem through the device node- and you'll note that Linux
certainly has got an independent set of permissions for that called the
capabilities system. That's because messing with those pieces can crash
the kernel. You're not going to crash the kernel if you goof up
/etc/shadow.
Thanks!
Stephen
