By gentoo's default the postgres socket have 777 permissions, and the dir /run/postgresql is 770 postgres:postgres, the gentoo's docs about setting up postgres located at http://www.gentoo.org/doc/en/postgres-howto.xml stats that I suppose to add for example apache to postgres group to allow it connect over socket instaed of TCP. The issue is that I am getting write access to that very dir, so I can remove and replace the pgsql socket with my own, to hijack data and passwords from anything that connect thru this socket. Setting the dir to 755 or 750 would be by far better idea. Reproducible: Always
Good point. I'll change it to 750 soon enough. For the time being, you can modify the initscript on line 64 yourself to impose the change.
I still worry about adding people to postgres group, as the deamon itself runs as this group I believe. The only thing it is pretecting against is connecting to socket, but also by default postgres bind to localhost:5432 so anything localy can connect to it. What you think about making it 755 root:root instead?
Please don't adjust the importance. It isn't critical especially when an easy, user-implementable fix is available. It has been changed to 750 postgres:postgres in the pgsql-patches git repo. Yes, anything connecting to localhost by default has access, but the kind recommends that you enable the password method on localhost.
I think think that socket should be accessable accessable even without postgre group, just like TCP on localhost, as the socket is much faster and user have to adjust postgresql config anyway way to make it more secure, so blocking one of two basic and open by default ways to access it is a bit wrong. Please reconsider making it 755 postres:postres.
To clarify my point, you can either add user X to postgres group (which gives user access to the service's group and is far from good idea in my opinion) or you can append '-h localhost' to psql. Of course you can disable binding to TCP port but you can also disable binding to unix socket.
(In reply to comment #5) > To clarify my point, you can either add user X to postgres group (which > gives user access to the service's group and is far from good idea in my > opinion) or you can append '-h localhost' to psql. Of course you can disable > binding to TCP port but you can also disable binding to unix socket. The more I think about it now, this is probably the best argument for 775/postgres:postgres. The recommendation for adding various users and services to the `postgres' system group would need to go away. The reason for maintaining 775/postgres:postgres being the various PostgreSQL related daemons that need to create their own sockets, usually in the same directory. For example, an admin would probably make PgBouncer take the default socket location and file name and have the server listen on a non-standard socket so that clients connect through PgBouncer instead of directly to PostgreSQL. I'll need to look at the other daemons and see what changes I have to make, and probably do so en masse.
Well, a while back in (https://bugs.gentoo.org/show_bug.cgi?id=449400) I already noted, that setting the permissions is a problem, or actually, the problem is, that you cannot 'keep' the permissions between reboots. As I noted in my bug report, if you group users, you'd usually use ACLs as a sane measure to grant access to files (the UD socket in this case). While you are at reviewing the scripts, and preset permissions, maybe add the opportunity, to let the admin set the permissions depending on his setup, while giving a sane preset for most people (which imho includes read access to the socket for all users). I still believe, similiar as Piotr, that sticking daemons (et al) into the postgres group is not an appropriate measure.
(In reply to comment #7) > Well, a while back in (https://bugs.gentoo.org/show_bug.cgi?id=449400) I > already noted, that setting the permissions is a problem, or actually, the > problem is, that you cannot 'keep' the permissions between reboots. > > As I noted in my bug report, if you group users, you'd usually use ACLs as a > sane measure to grant access to files (the UD socket in this case). While > you are at reviewing the scripts, and preset permissions, maybe add the > opportunity, to let the admin set the permissions depending on his setup, > while giving a sane preset for most people (which imho includes read access > to the socket for all users). > > I still believe, similiar as Piotr, that sticking daemons (et al) into the > postgres group is not an appropriate measure. Your arguments on bug 449400 stemmed from laziness, as it seemed to me. Piotr's arguments stem from a security viewpoint. So, while the intention may have been the same, the pitch is different. The daemons that would be in the `postgres' system group are those that are PostgreSQL-related programs, such as PgBouncer and pgpool-II. In other words, programs that are intended to appear as PostgreSQL to the client. Note that Apache is not related to PostgreSQL, so it will not appear in that list. With a permission of 775 on the directory, users not in the `postgres' group will be able to access the socket just fine, they just won't be able to delete or create files within the socket directory. Meanwhile, PgBouncer and pgpool-II will be able to create and delete their socket files just fine. My hesitancy to make it user configurable is because of checkpath. It doesn't just create the directory, it modifies the permissions of the directory as well. If a user changes the permissions for one of the daemons, but not the other two, they won't get what they're expecting. If we're striving for simplicity, making permissions user configurable will not help. If we striving for difficulty and obscurity, we can certainly add it.
(In reply to comment #8) > (In reply to comment #7) > > Well, a while back in (https://bugs.gentoo.org/show_bug.cgi?id=449400) I > > already noted, that setting the permissions is a problem, or actually, the > > problem is, that you cannot 'keep' the permissions between reboots. > > > > As I noted in my bug report, if you group users, you'd usually use ACLs as a > > sane measure to grant access to files (the UD socket in this case). While > > you are at reviewing the scripts, and preset permissions, maybe add the > > opportunity, to let the admin set the permissions depending on his setup, > > while giving a sane preset for most people (which imho includes read access > > to the socket for all users). > > > > I still believe, similiar as Piotr, that sticking daemons (et al) into the > > postgres group is not an appropriate measure. > > Your arguments on bug 449400 stemmed from laziness, as it seemed to me. > Piotr's arguments stem from a security viewpoint. So, while the intention > may have been the same, the pitch is different. > That is not entirely true. With xx0, you'd have to move daemons into the postgres group. Further all system users, that are part of a group, would have to move individually into the postgress group, otherwise they couldn't access the socket. Using ACLs to have fine granularity in access control, not sticking all kinds of users, which is madatory for xx0, is a security question and nothing else. > The daemons that would be in the `postgres' system group are those that are > PostgreSQL-related programs, such as PgBouncer and pgpool-II. In other > words, programs that are intended to appear as PostgreSQL to the client. > Note that Apache is not related to PostgreSQL, so it will not appear in that > list. Which is true for xx5, but not xx0, and we are not talking about apache alone, it was merely an example to show the group polluting problem. If access is not granted to all users on the socket, rendering it unusable for all users outside the postgres group, the only way to give appropriate access and control it are ACLs, and there needs to be a way, to load these, as /run is on tmpfs. I'd be worried, if people consider polluting a group being good practise, but that's just my POV.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Well, a while back in (https://bugs.gentoo.org/show_bug.cgi?id=449400) I > > > already noted, that setting the permissions is a problem, or actually, the > > > problem is, that you cannot 'keep' the permissions between reboots. > > > > > > As I noted in my bug report, if you group users, you'd usually use ACLs as a > > > sane measure to grant access to files (the UD socket in this case). While > > > you are at reviewing the scripts, and preset permissions, maybe add the > > > opportunity, to let the admin set the permissions depending on his setup, > > > while giving a sane preset for most people (which imho includes read access > > > to the socket for all users). > > > > > > I still believe, similiar as Piotr, that sticking daemons (et al) into the > > > postgres group is not an appropriate measure. > > > > Your arguments on bug 449400 stemmed from laziness, as it seemed to me. > > Piotr's arguments stem from a security viewpoint. So, while the intention > > may have been the same, the pitch is different. > > > > That is not entirely true. With xx0, you'd have to move daemons into the > postgres group. Further all system users, that are part of a group, would > have to move individually into the postgress group, otherwise they couldn't > access the socket. > > Using ACLs to have fine granularity in access control, not sticking all > kinds of users, which is madatory for xx0, is a security question and > nothing else. > > > The daemons that would be in the `postgres' system group are those that are > > PostgreSQL-related programs, such as PgBouncer and pgpool-II. In other > > words, programs that are intended to appear as PostgreSQL to the client. > > Note that Apache is not related to PostgreSQL, so it will not appear in that > > list. > > Which is true for xx5, but not xx0, and we are not talking about apache > alone, it was merely an example to show the group polluting problem. > > If access is not granted to all users on the socket, rendering it unusable > for all users outside the postgres group, the only way to give appropriate > access and control it are ACLs, and there needs to be a way, to load these, > as /run is on tmpfs. > > I'd be worried, if people consider polluting a group being good practise, > but that's just my POV. This reads like you're not understanding I'm going to modify all the PostgreSQL-related initscripts to 775.
(In reply to comment #10) > > This reads like you're not understanding I'm going to modify all the > PostgreSQL-related initscripts to 775. Which is a sane preset, as I stated in my older bug report, and why. Anyhow, I am still saying, that it would be reasonable, that if we want to control access to the socket by means of file permissions (if an admin considers this a better setup), it should be possible to override the default. If security is a matter, a setup like 0xy0 together with specific ACLs for those UIDs/GIDs that should have explicit acces to the socket might be preferred by admins. Usually all local connections are handled via the UD socket for performance reasons. If it is not available, one could use the TCP socket (with impact on performance) if and only if tcp connectivity is provided. If we assume that access through the TCP socket is possible, then a UD socket with full read access behaves similiar, there are a few differences and catches though, which I want to point out: TCP connectivity can be disabled TCP sockets can be bound to specific addresses and thus interfaces for that matter (no lo TCP socket) Additionally packets on lo traverse the network layer and as such access on the TCP socket can be controlled via netfilter (ex.: owner matching) These things can be controlled within pg's configuration or via netfilter and are left to the admin and the excact setup he runs. As a conclusion, having the (default) UD socket as IPC Interface for local connections readable for world becomes a sane preset to ensure local connectivity as UD is the default connection type anyway and a good fallback for disabled TCP connectivity. Now while I can control TCP access in various ways, UD access control is only doable via file permissions and if it is decided to enforce access restrictions this should be possible. As the socket is created on every startup, Access Control settings (permissions+ACLs) are not persistent and can not easily be set (except maybe by doing all changes in an additional init script or 'local'). All these factors led me to the conclusion, that a sane preset (which 755 seems to be), should be established, but at the same time should be overrideable by an admin, to enfore his/her policies. Consider the preset as an all world normal user default, that makes things work for him (any many others), while giving an admin the possibility of setting permissions, if he wants to, without throwing rocks into his way. Back when the socket was not yet on tmpfs such things were out of the responsibility of the init script, as changes usually were persistent over restarts. These are just my 3 1/2 cents on security, permissions and automated file creation on tmpfs in init scripts. In general these are things to consider in ANY initscript, since IPC sockets were moved onto a tmpfs. (Probably checkpath needs a major rework, as it does not offer ACL handling and is used in various scripts) One last thought on security, all packets on lo can be grabbed with CAP_NET_RAW_SOCKET (If I am not mistaken) and CAP_NET_ADMIN, which can compromise the communication when done via TCP sockets rather easy. An IPC socket(UD socket) is merely a piece of (in kernel? VFS layer?) memory with defined interface. The question is, can the communication stream on a UD socket be intercepted as easily and with as little CAPs as for the loopback interface? This might be another argument for preferring the UD socket and making it usable by world (besides performance)
The actual socket permissions are set by postgresql.conf via unix_socket_permissions and the owning group can be modified as well. So, while /run/postgresql may be 0775 postgres:postgres, the socket itself can be 0770 postgres:pgdbas. Unix domain sockets are secure. On Linux, Unix domain sockets are not susceptible to eavesdropping. To be able to get anything malicious done via the socket, a user would have to have elevated privileges, in which case, socket permissions are the least of the DBA's or SA's concern. As for ACLs, patches are welcome.
