Re: pgsql: Adjust user-facing documentation to explain why we don't check

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Dave Page <dpage(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)postgresql(dot)org>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Adjust user-facing documentation to explain why we don't check
Date: 2007-02-20 19:35:49
Message-ID: 200702201935.l1KJZnK05374@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers


I updated the documentation to say:

On Microsoft Windows, it is assumed that the file is stored in a
directory that is secure, so no special permissions check is made.

This might be as good as we can get.

---------------------------------------------------------------------------

Magnus Hagander wrote:
> Dave Page wrote:
> > Magnus Hagander wrote:
> >>>> PGPASSFILE takes a full path name, so you can put the file anywhere you
> >>>> want. Just like on Unix.
> >>> OK, so we _do_ need to check the permissions on pgpass on Win32, but we
> >>> just don't know how to do that?
> >>>
> >> If we _need_ to check, I don't know. If you've set PGPASSFILE to
> >> something, then you've made a decision to change from the default, and
> >> it could be argued that we don't have to check for that. It can of
> >> course equally well be argued that we should, yes.
> >
> > Not necessarily - wasn't that one of the suggestions given to Tony
> > during our recent disagreement on pgpass files? Users may not realise
> > their app is setting PGPASSFILE.
>
> Well, if you don't trust your app, why are you running it ;-)
>
>
> >> Which would bring is to the "how". If there was an easy way to do the
> >> how, we should probably do it. However, I'm very concerned that we will
> >> break a whole lot more than we fix because the permissions system is
> >> much more complex.
> >
> > I think the only thing you could do would be to specify that the user
> > and only the user have full control over the file. *Any* other ACL
> > entries, deny or allow, are not allowed. Access via a group is not allowed.
>
> That will break every default install in the world. They will all
> contain at least ACLs for Administrators and SYSTEM. If they're in a
> domain, also the admins from the domain. Not sure about power users. And
> in a domain, it's not uncommon at all to push down a group of people in
> IT who have access to users profiles to fix things. Etc.
>
>
> > Now the next problem is how this should be set on Home Editions which do
> > their best to hide ACLs from the user. I suppose we could just document
> > the correct cacls command line to get exactly the acl we want.
>
> I seriously don't think that will ever work, if we're broken on the
> *default install*. If we're fine on default, and someone has changed it,
> then they can likely fix it if they have the instructions. But if we
> break the default install, we're out.
>
> //Magnus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Dave Page 2007-02-20 19:42:50 Re: pgsql: Adjust user-facing documentation to explain why we don't check
Previous Message Bruce Momjian 2007-02-20 19:35:17 pgsql: Update pgpass Win32 wording.