Re: proposal: hide application_name from other users

On Fri, Jan 24, 2014 at 5:21 PM, Harold Giménez <harold(at)heroku(dot)com> wrote:

> On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> >
> > On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
> >>
> >> On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >> > Probably Heroku has some more specific exploit case to be concerned
> >> > about here; if so, might I suggest taking it up with the -security
> list?
> >>
> >> I don't think there's a specific vulnerability that needs to be kept
> >> secret here.
> >>
> >> Here's an example. I just created a new "hobby" database which is on a
> >> multi-tenant cluster and ran select * from pg_stat_activity. Here are
> >> two of the more interesting examples:
> >>
> >> 463752 | de5nmf0gbii3u5 | 32250 | 463751 | qspfkgrwgqtbcu | unicorn
> >> worker[1] -p 30390 -c ./config/unicorn.rb | |
> >> | | |
> >> | |
> >> | | | <insufficient privilege>
> >> 463752 | de5nmf0gbii3u5 | 32244 | 463751 | qspfkgrwgqtbcu | unicorn
> >> worker[0] -p 30390 -c ./config/unicorn.rb | |
> >> | | |
> >> | |
> >> | | | <insufficient privilege>
> >>
> >>
> >> Note that the contents of the ARGV array are being set by the
> >> "unicorn" task queuing library. It knows it's making this information
> >> visible to other users with shell access on this machine. But the
> >> decision to stuff the ARGV information into the application_name is
> >> being made by the Pg driver. Neither is under the control of the
> >> application author who may not even be aware this is happening.
> >> Neither component has the complete information to make a competent
> >> decision about whether this information is safe to be in
> >> application_name or not.
> >>
> >> Note that the query is showing as "<insufficient privilege>" even
> >> though it is listed in the ps output -- the same ps output that is
> >> listing the unicorn ARGV that is being shown in the
> >> application_name....
> >>
> >> You might say that the Pg gem is at fault for making a blanket policy
> >> decision for applications that the ARGV is safe to show to other
> >> database users but realistically it's so useful to see this
> >> information for your own connections that it's probably the right
> >> decision. Without it it's awfully hard to tell which worker is on
> >> which connection. It would just be nice to be able to treat
> >> application_name the same as query.
> >
> >
> > I would say that yes, this is clearly broken in the Pg gem. I can see it
> > having such a default, but not allowing an override...
>
> Uhm, it does allow an override as I said before.
>

Oops, sorry, I missed that when reading back in the thread.

> > The application can of course issue a SET application_name, assuming
> there
> > is a hook somewhere in the system that will run after the connection has
> > been established. I've had customers use that many times in java based
> > systems for example, but I don't know enough about the pg gem, or
> unicorn,
> > to have a clue if anything like it exists there. This is also a good way
> to
> > track how connections are used throughout a pooled system where the same
> > connection might be used for different things at different times.
> >
> > What actually happens if you set the application_name in the connection
> > string in that environment? Does it override it to it's own default? If
> so,
> > the developers there clearly need to be taught about
> > fallback_application_name.
>
> It can be overridden using any of these methods. It does in fact use
> fallback_application_name when it defaults to $0, see
>
> https://bitbucket.org/ged/ruby-pg/src/6c2444dc63e17eb695363993e8887cc5d67750bc/lib/pg/connection.rb?at=default#cl-46
>
> >
> > And what happens if you set it in PGAPPNAME?
>
> It works fine:
>

...

With that many options of "hiding" it, I would still argue for just picking
one of those.

For example, of Heroku wants to protect their customers against the
behaviour of the pg gem, you can for example set PGAPPNAME in the
environment. That will override what the gem sets in
fallback_application_name, but those users that actually use it and specify
it in their connection string, will override that default.

And all of that without removing a valuable debugging/tracing tool from
other users.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/