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

Magnus Hagander wrote:

> Well, if you don't trust your app, why are you running it ;-)

Theres a world of difference between trusting your app and knowing what
it's doing.

>>> 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.

Yes - and not knowing who is/should be in the default ACL is exactly the
problem.

The only thing that will *break* though is libpq which would do the same
thing as it would on *nix if the mode was 0622 or whatever. It's not
going to break Windows or the users profile if the ACL on their pgpass
file is tightened up.

>> 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.

huh?

/D