Robert Haas <robertmhaas@gmail.com> writes:
> I think clarifying the warning is probably an acceptable change as
> long as the new wording is equally clear and doesn't add much to the
> length of the message. Of course, I don't have the only vote here.
It's totally fair to say that this message needs clarification.
> Changing the warning to an error wouldn't bother me a great deal, but
> we'd probably need more than just you voting for that alternative to
> justify overturning longstanding behavior.
Agreed.
> I don't really know what I think about allowing group permissions.
> It's reasonable in the sense that we have an option to allow that for
> $PGDATA, but OTOH we have no real understanding of Windows permissions
> or Linux ACLs or SELinux security constraints, so that idea that we
> can force "safe" permissions is a little bit laughable.
As I recall, at the time this code was added, it was not at all
unusual for systems to be set up with all users being members of
a group named "users" or so, and even for that to be the default
group for new files, so that granting group read was not a lot
tighter than granting world read. It looks like macOS and Solaris
at least are still that way --- they call the group "staff" not
"users", but the problem is the same. NetBSD uses "users"; I did
not check other BSDen. But it sure looks like "group per user
by default" may be a Linux-ism.
So I'm pretty down on allowing group read here, at least as a default
behavior. Maybe there could be some kind of option to allow it,
but again I'd like more than one request per quarter-century before
we go to the trouble. (I note also that the holes we've poked for
group access to $PGDATA and SSL key files were poked in response to
extremely concrete, hard-to-work-around use-cases, which is something
I'm not hearing here.)
regards, tom lane
