Robert Haas <robertmhaas@gmail.com> writes: > OK, great. The latest patch doesn't specifically talk about backing it > up with filesystem-level controls, but it does clearly say that this > feature is not going to stop a determined superuser from bypassing the > feature, which I think is the appropriate level of detail. We don't > actually know whether a user has filesystem-level controls available > on their system that are equal to the task; certainly chmod isn't good > enough, unless you can prevent the superuser from just running chmod > again, which you probably can't. An FS-level immutable flag or some > other kind of OS-level wizardry might well get the job done, but I > don't think our documentation needs to speculate about that.
True. For postgresql.conf, you can put it outside the data directory and make it be owned by some other user, and the job is done. It's harder for postgresql.auto.conf because that always lives in the data directory which is necessarily postgres-writable, so even if you did those two things to it the superuser could just rename or remove it and then write postgresql.auto.conf of his choosing.
Just to add to that -- if you use chattr +i on it, the superuser in postgres won't be able to rename it -- only the actual root user.
Just chowning it won't help of course, then the rename part works.