Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 449400 - dev-db/postgresql-server-9.2.1 broekn permissions on UD-socket
Summary: dev-db/postgresql-server-9.2.1 broekn permissions on UD-socket
Status: RESOLVED DUPLICATE of bug 395331
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PgSQL Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-31 05:44 UTC by Sven E.
Modified: 2013-01-28 14:00 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven E. 2012-12-31 05:44:31 UTC
dev-db/postgresql-server-9.2.1 has wrong permissions on it's unix-domain socket. Bug is in the init script, where the mode of the file is set.

Reproducible: Always

Steps to Reproduce:
1.emerge dev-db/postgresql-server-9.2.1
2.set up cluster
3.try accessing db with unpriv'd systemuser.
Actual Results:  
Connection to UD socket fails.

Expected Results:  
Connection to UD socket should work for every systemuser.

From the init script:
checkpath -d -m 0770 -o postgres:postgres ${socket_path}

Of course users aside from postgres and root need to be able to access the UD socket. 

In the current version nearly everything fails to connect to PG in local context.

Mode should be set to 0775 rather than 0770
Comment 1 Mike Gilbert gentoo-dev 2012-12-31 06:14:23 UTC
From pkg_postinst:

    elog "If you have users and/or services that you would like to utilize the"
    elog "socket, you must add them to the 'postgres' system group:"
    elog "    usermod -a -G postgres <user>"

Is there some reason you cannot do this?
Comment 2 Sven E. 2012-12-31 07:25:48 UTC
Okay, I could add all the daemons to the postgres group, but is that really reasonable? 

Shouldn't access to the RDBMS only be handled by the RDBMS? Instead of the filesystem?

I am just not feeling comfortable with sticking all daemons, having their own group anyway, into the postgres group additionally.

And what about i.e. apache+suexec - would we really want dozens of users in the postgres system group and among them some daemons, to always loose track?

How about this:

Provide the current values (mode+ownership) as presets and make them overrideable via conf.d - This way the admin decides, what he/she thinks is reasonable for the setup facing.
Comment 3 Aaron W. Swenson gentoo-dev 2013-01-28 02:33:19 UTC
Upstream recommends that the permissions on the sockets' directory be what I have default them to and I won't provide the means for a user to shoot themselves in the foot. However, I cannot keep you from editing the initscript.

It is as reasonable to expect the administrator to keep track of who has permissions to access the socket as anything else he or she needs to keep track of.

*** This bug has been marked as a duplicate of bug 395331 ***
Comment 4 Sven E. 2013-01-28 14:00:29 UTC
(In reply to comment #3)
> Upstream recommends that the permissions on the sockets' directory be what I
> have default them to and I won't provide the means for a user to shoot
> themselves in the foot. However, I cannot keep you from editing the
> initscript.
> 
> It is as reasonable to expect the administrator to keep track of who has
> permissions to access the socket as anything else he or she needs to keep
> track of.
> 
> *** This bug has been marked as a duplicate of bug 395331 ***

Okay, but usually you could just change permissions. The problem is having the socket on tmpfs and hardcoding the permisions. And yes, I do know, I can change the script.

Maybe I am having a different perspective, as I use ACLs consequently. With ACLs you move away from that last millenium concept of creating a group for every specific access purpose and sticking all users into it, since you have the option to add multiple groups and users to the ACL of an object.