Re: pgsql: Adjust user-facing documentation to explain why we don't check
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: Adjust user-facing documentation to explain why we don't check |
Дата | |
Msg-id | 200702201935.l1KJZnK05374@momjian.us обсуждение исходный текст |
Ответ на | Re: pgsql: Adjust user-facing documentation to explain why we don't check (Magnus Hagander <magnus@hagander.net>) |
Список | 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@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-committers по дате отправления: