Tom Lane writes:
Andres Freund and...@2ndquadrant.com 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
On 2013-09-09 21:41:00 +0200, Daniel Vérité wrote:
Tom Lane writes:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com writes:
On 2013-09-09 21:41:00 +0200, Daniel Vérité wrote:
Tom Lane writes:
That would only stop symlink attacks, not hardlink variants;
The creation of the hardlink is denied by the OS based on the
attacker not having sufficient permissions to the target
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
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
On 2013-09-08 20:00:58 +0200, Daniel Vérité wrote:
Or is there a simpler way to deal with the above case?
One would be to use open(O_NOFOLLOW)?
But more generally I am of the opinion that it's the superusers
responsibility to make sure that cannot happen by only using properly
secured files.
Andres Freund and...@2ndquadrant.com writes:
On 2013-09-08 20:00:58 +0200, Daniel Vérité wrote:
Or is there a simpler way to deal with the above case?
One would be to use open(O_NOFOLLOW)?
That would only stop symlink attacks, not hardlink variants;
and it'd probably stop some legitimate
