Skip site navigation (1) Skip section navigation (2)

Re: For review: Server instrumentation patch

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: For review: Server instrumentation patch
Date: 2005-07-24 20:59:45
Message-ID: 42E40141.7010501@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Magnus Hagander wrote:

>>>How is this different from the fact that the superuser can 
>>>      
>>>
>>already use 
>>    
>>
>>>COPY to accomplish the same thing?
>>>      
>>>
>>COPY can accomplish a few of the same things, much less 
>>conveniently (for instance, it's darn hard to write an 
>>arbitrary binary file through COPY).
>>    
>>
>
>Right. But the *security* problem is more or less equal. If somebody
>hacks your superuser account, they can make at least almost the same
>amount of damage. It may take a little more work, but if you just want
>to kill the system by overwriting files, or overwriting say the password
>file, it's just as easy. And if what you want to do is stick some kind
>of executable o nthe system, you can just wrap it in a shellscript that
>will unpack it.
>  
>

It could be argued that there should be provision for a limitation on 
the locations in which COPY can write (and maybe read) files.

If COPY is a security hole then we should close it, not use that as 
precedent to open another hole.

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-07-24 22:12:52
Subject: Re: For review: Server instrumentation patch
Previous:From: Magnus HaganderDate: 2005-07-24 20:37:18
Subject: Re: For review: Server instrumentation patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group