Bruce Momjian wrote:
> Tom Lane wrote:
>
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>
>>> Tom Lane wrote:
>>>
>>>> I wonder if we should take pg_read_file (and the rest of genfile.c)
>>>> back out of the backend and stick them into contrib/adminpack.
>>>>
>>> I thought about that but what we have in the backend now is read-only
>>> which basically could be done using COPY, so I don't see any security
>>> value to moving them out. They are super-user only just like COPY.
>>>
>> The you-can-do-it-with-COPY argument doesn't apply to pg_ls_dir, nor to
>> pg_stat_file, and I find it unconvincing even for pg_read_file. COPY
>> isn't at all friendly for trying to read binary files, for instance.
>> Even for plain ASCII text you'd have to try to find a delimiter
>> character not present anywhere in the file, and backslashes in the file
>> would get corrupted.
>>
>> But the basic point here is that someone who wants filesystem access
>> from the database is going to install adminpack anyway. Why should
>> someone who *doesn't* want filesystem access from the database be
>> forced to have some capabilities of that type installed anyway?
>>
>
> Remember we went around and around on this with the pgAdmin guys, so you
> are going to have to get their input. Also consider that pgAdmin might
> be doing remote administration on a database it can't load shared
> objects into, so having the read stuff always be there might help them.
>
> I don't see anyone complaining about our read-only file access in the
> backend, so I don't see a readon to remove it.
>
>
For the record, I am not happy with forcing this either. Providing it in
an optional module seems perfectly reasonable to me. I suppose an
alternative would be to turn the capability on or off via a (yet
another) switch.
cheers
andrew
