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