Re: [HACKERS] file_fdw target file ownership
Andres Freund writes > andres@alap2:~$ ls -l /tmp/frak > -rw-r- 2 root shadow 1652 Jun 4 22:05 /tmp/frak Ah, indeed. It fails for me though (Ubuntu 12.04, linux 3.2.0, ext4): $ ln /etc/shadow /tmp/frak ln: failed to create hard link `/tmp/frak' => `/etc/shadow': Operation not permitted but I can see it succeed on older linux. Still $PGDATA with its rwx-- permissions is insulated from any such hard-linking from outsiders, whereas a soft link can point anywhere. Best regards, -- Daniel Vérité PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] file_fdw target file ownership
Tom Lane writes: > Andres Freund writes: > > One would be to use open(O_NOFOLLOW)? > > That would only stop symlink attacks, not hardlink variants; > and it'd probably stop some legitimate use-cases too. The creation of the hardlink is denied by the OS based on the attacker not having sufficient permissions to the target file. In principle the mentioned loophole is limited to a symlink, which is not restricted at create time. Thinking a bit more about the scenario of the malicious writer, I think the secure way to proceed for the superuser would be to set up two directories, one with write permissions to the producer of data, the other without. The superuser would have to move the file from the writable dir to the non-writable dir, before creating the foreign table. The file itself should remain writable by the uploader if it's live data. The data-producer has to be aware that updates happen at a different path than uploads. The problem is that it's really not intuitive. I can imagine unaware admins implementing the insecure process without a second thought. By contrast, if symlinks were followed only optionally, it would be safer as a default choice and the installations that need symlinks could still use something like: CREATE FOREIGN TABLE (...) SERVER name OPTIONS (symlink_allowed 'on', filename '/path/to/file', ...) The mere existence of the option is a hint that there are consequences to consider. Best regards, -- Daniel Vérité PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] file_fdw target file ownership
Hi, When a superuser creates a foreign table with file_fdw, the target file can belong to any user, as long as postgres can read it. This is useful when the data files are handed by non-postgres tools, such as a spreadsheet. In such a case, it makes sense that the superuser would additionally grant SELECT on the foreign table to a non-superuser to process the contents. But once the foreign table is set up, a malicious user owning the file or even the containing directory can replace it by a link to any file that can be read only by postgres, such as the server's private key. With SELECT permission granted on the table, the non-superuser can then proceed to read the contents in SQL. I've tried it successfully with 9.3rc1. As a result, it means that an admin should not allow a file as the target of a foreign table if it can be replaced on the filesystem by a non-postgres user. It may be writable by a non-postgres user, though, which is quite useful with moving data. This is a bit subtle. To avoid the whole issue, how about adding an option in file_fdw forcing it to check each time it opens the file that its ownership and maybe permissions have not changed since CREATE FOREIGN TABLE? Or is there a simpler way to deal with the above case? Best regards, -- Daniel Vérité PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
