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

[Bráulio Bhavamitra < >]

Em 22/06/2014 21:24, "Bráulio Bhavamitra" < "> > escreveu:

Hello James,

I pretty much like your ideas. The suggestion I have is to make the peer auth an option:
mysql_database do
  peer_auth true
end

Something like this.

Cheers,
Braulio

Em 17/06/2014 18:47, "James Le Cuirot" < " target="_blank"> > escreveu:

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.

What do you think?

Regards,
James