Re: [PG19-3 PATCH] Don't ignore passfile
От | Tom Lane |
---|---|
Тема | Re: [PG19-3 PATCH] Don't ignore passfile |
Дата | |
Msg-id | 511926.1757353601@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PG19-3 PATCH] Don't ignore passfile (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PG19-3 PATCH] Don't ignore passfile
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: