[chef] Re: database cookbook suggestion: Shell out for peer authentication?

[Noah Kantrowitz < >]

On Jun 17, 2014, at 2:46 PM, James Le Cuirot 
<
 >
 wrote:

> Hello list,
> 
> I've been adding a postgresql recipe for the rsyslog cookbook to
> provide out-of-the-box PostgreSQL backend support. It's working well
> but something has been bothering me.
> 
> MySQL users have traditionally used password authentication but
> PostgreSQL has put equal emphasis on peer authentication, where the
> user is given access without a password on the basis that they are
> already connected via the operating system user of the same name.
> Obviously this only works for local socket connections.
> 
> I have always liked this concept. Why waste time and effort trying to
> hide a password when one isn't even necessary? If an intruder has
> already gained shell access to the account then it's probably game
> over anyway.
> 
> Unfortunately the database cookbook doesn't cater for this concept at
> all. It connects using the pg gem, meaning that the operating system
> user is (almost?) always root. I've been thinking about whether it
> would be possible for the "db" method to shell out to psql via su,
> allowing peer authentication from any local user. This has a few
> benefits.
> 
> Obviously it negates the need for many users to have a password. This
> also applies to the postgres user, which currently has a password
> randomly generated by default, and I gather there are problems
> surrounding this.
> 
> It would also mean that the installation of "build-essential" could
> potentially be avoided. This consumes substantial time and bandwidth
> and I was rather disappointed to see it being installed on what I had
> hoped would be rather minimal boxes.
> 
> MySQL could also reap these benefits. It's probably not widely used but
> it has supported peer authentication since 5.5.10.
> 
> You may be thinking that I could just do all my recipe database
> operations as the postgres user with a password and allow other users
> to connect using peer authentication from their respective applications.
> This generally doesn't work because any tables, sequences, and other
> such things that get created are then owned by the postgres user.
> Granting any other user access to these is very tedious, short of
> making them a superuser. The most practical solution is for the end
> user to create these objects in the first place.
> 
> There are certain things to be aware of. psql should work in all cases
> but su might not. What if the server is remote? Connecting to a socket
> requires passing a path so one could just check to see whether "host"
> starts with a slash. What if chef-client is not being run as root? I'm
> not sure if that's a supported use case but I have heard of it. In that
> case, passwords will be necessary so simply don't use su. And what
> about operating system support? The docs say that peer authentication
> should work on Linux, most flavors of BSD including Mac OS X, and
> Solaris. Like the non-root case, Windows could just connect without su.
> 
> Any drawbacks? The pg gem provides nice exceptions when things go wrong
> but I don't think Chef has a mechanism to intelligently react to these
> so there's probably no big loss there. Some may think that shelling out
> is just nasty and I would usually agree but Chef does plenty of it
> already and I think the benefits far outweigh this concern. I honestly
> can't think of anything else.

The primary drawback is that unless your application is a toy or experiment, 
you will have more than one server (usually at least 4, 2x web 2x DB for 
reliability). In this situation peer auth can't be used and because it is by 
far the more common case, complicating the code to support peer auth for 
single-server situations just isn't worthwhile.

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail