Live data from Hacker News

CVE-2019-9193: Not a Security Vulnerability

postgresql.org

81–84 of 84 posts

Re: CVE-2019-9193: Not a Security Vulnerability

#81

Earlier quoted context omitted.

What is way way faster here? Are you only comparing COPY versus individual row INSERT statements? I prefer using COPY ... STDIN/STDOUT. AFAICT, you get the same bulk table access performance. But, the external file access is via the client, separating DB rights and filesystem rights. When appropriate, you can also SSH to the server and invoke psql as a regular user there, manipulating files under that user's control…

You're missing the point. COPY TO/FROM PROGRAM is useful e.g. when you already have the data locally on the server (same filesystem, ...). COPY FROM STDIN/STDOUT are useful when the data are on some other system (say, on a different server, etc). Of course, you might write a script that reads the local data and loads it through a regular client, i.e. something like COPY t FROM PROGRAM 'gunzip -c /path/to/compressed/d…

I'm not missing the point. I was responding to a comment about performance. In my experience, COPY ... STDIN/STDOUT are just as fast the other COPY, given the same filesystems. I think many people are unnecessarily conflating bulk COPY advantages with superuser rights here.

We use it all the time via psql authenticated with unix domain socket. In most situations where there are users performing ETL and such, I think it is much safer to have them using a non-superuser role and manipulating files in their own user or group space. You can have all the performance of a bulk COPY without the risk of mangling the service-related files under the postgres user. I think it is better to give regular SSH accounts to these users than to give them elevated DB privileges so they can use server-side file or program COPY.

Also, with psql you can do \copy ... program within your SQL script. It has all the expressive power of a server-side copy but actually runs commands under the invoking user instead of the postgres service.

Re: CVE-2019-9193: Not a Security Vulnerability

#82

Earlier quoted context omitted.

How do you configure execute rights securely? I’ve skimmed over the docs. Execute right allows user to execute programs under postgres Unix account, so getting control of postgres database account should be possible. Basically execute right = superuser. Why even have a separate right for that? Just assign superuser role.

Because enough users asked for them - there was a long debate about that. It's less to prevent those users from intentionally gaining superuser, and more to make it a bit harder to unintentionally have trusted users shoot themselves into the foot. The docs say at https://www.postgresql.org/docs/current/default-roles.html#D... "The pg_read_server_files, pg_write_server_files and pg_execute_server_program roles are int…

Thanks, that makes sense. I still think that enough people don't read documentation carefully and might unintentionally introduce vulnerability into their database systems, but probably they would find enough ways to shoot themselves in the foot anyway.

Re: CVE-2019-9193: Not a Security Vulnerability

#83
post #41

Earlier quoted context omitted.

If you make a proxy account, AS AN ADMIN. I have personally walked dozens of DBAs through making said proxy account as it was non-trivial to accomplish. Please stop repeating this FUD.

The quote's from me, and even in the quoted part explicitly says "if you have a privileged account". And an admin user you just need to enable it, and it works without even the proxy user configured. Please explain what's FUD about that? The postgres equivalent this post is about a feature that's only granted to superusers (or in recent version user that have explicitly been granted rights that are equivalent to supe…

The FUD is someone saying Microsoft didnt lock down the xp_cmdshell functionality (which is the post I replied to.)

I agree that the postgres and msft functionality effectively have the same level of permissions required, which is that an admin level user must take specific steps to allow this to occur.

Re: CVE-2019-9193: Not a Security Vulnerability

#84
post #83

Earlier quoted context omitted.

The quote's from me, and even in the quoted part explicitly says "if you have a privileged account". And an admin user you just need to enable it, and it works without even the proxy user configured. Please explain what's FUD about that? The postgres equivalent this post is about a feature that's only granted to superusers (or in recent version user that have explicitly been granted rights that are equivalent to supe…

The FUD is someone saying Microsoft didnt lock down the xp_cmdshell functionality (which is the post I replied to.) I agree that the postgres and msft functionality effectively have the same level of permissions required, which is that an admin level user must take specific steps to allow this to occur.

Well, the comment was in reply to somebody asking for the postgres feature to be locked down similar to MSSQL's - and I think the "FUD" spreading commenter just was trying to explain that it's already similarly locked down. Sure, it could have been a bit more explicit about that, but attacking that as FUD seems mighty strong.
Post reply on HN