Re: [GENERAL] [BUGS] BUG #1830: Non-super-user must be able to copy from a
On Fri, Aug 19, 2005 at 09:15:52AM -0400, Stephen Frost wrote: > Personally, I do like the idea of a user-level 'copy server-side files' > permission that could be granted to reduce the need for things to run as > superuser. There is one important point though: The server copying things is seriously restricted. No matter how much authentication you do, the server cannot *become* you. Hence it cannot access your files unless they are world readable. For similar reasons, it cannot prevent the user from accessing the postgresql system files since it *is* the postgresql user and that cannot be changed. The UNIX way around this would be for the client to open the file with its permissions and then pass the FD to the server. But that's a rather interesting twist that only works on local sockets. > I'd probably still set up a SECURITY DEFINER function to a > user with those permissions as an additional layer of security but it'd > be nice to not have to run the function as superuser. Superuser is still limited by the system uid, that can't be changed. > It is, of course, good to note that current Postgres 'md5' auth method > usage means that a compromise of pg_shadow (pg_authid) gives the > attacker superuser access immediately (the hash itself is the actual > authentication token, the password isn't actually interesting in that > case). It's a compromise solution. Normal authentication (aka shadow file): server has only hash but password is in clear over the wire. MD5 auth: server knows the password (or enough to spoof) but it's not in the clear over the wire. Pick your poison... For true security use public key auth (certificates / keys / etc). Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpRzMbt0LKet.pgp Description: PGP signature
[BUGS] BUG #1838: IndexSupportInitialze
The following bug has been logged online: Bug reference: 1838 Logged by: Judith Altamirano Email address: [EMAIL PROTECTED] PostgreSQL version: Postgres95 Operating system: Red Hat 6.2 Description:IndexSupportInitialze Details: Hi, when I try to make a query it appears the next error: IndexSupportInitialize: corrupted catalos after of a table named suc_usr, I can't drop de table index neither the table... I would apreciatte if somebody know how can I fix the bug ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #1837: varchar/text operator "=" not unicode safe?
The following bug has been logged online: Bug reference: 1837 Logged by: Jörg Haustein Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Linux (SuSE 9.1) Description:varchar/text operator "=" not unicode safe? Details: I have a UNICODE database, trying to compare two unicode strings (Ethiopic characters). Client encoding is also UNICODE: testdb=> select 'á áµá© áá´á'='á°áá á¨á á°'; ?column? -- t (1 row) Clearly, it can be seen that they are not equal. The "LIKE" operator also seems to think so: testdb=> select 'á áµá© áá´á' LIKE 'á°áá á¨á á°'; ?column? -- f (1 row) What is the problem here? The behavior is the same with SQL_ASCII databases and the SQL_ASCII client encoding. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1838: IndexSupportInitialze
On Fri, Aug 19, 2005 at 07:32:41PM +0100, Judith Altamirano wrote: > > PostgreSQL version: Postgres95 Is that *really* the version you're running? What's the output of the following query? SELECT version(); -- Michael Fuhr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1838: IndexSupportInitialze
"Judith Altamirano" <[EMAIL PROTECTED]> writes: > PostgreSQL version: Postgres95 > Operating system: Red Hat 6.2 > Description:IndexSupportInitialze > Details: > Hi, when I try to make a query it appears the next error: > IndexSupportInitialize: corrupted catalos > after of a table named suc_usr, I can't drop de table index > neither the table... Postgres95!? Red Hat 6.2? My goodness, you are using ancient software. The list of known bugs fixed since those days would terrify anybody (and that goes for the whole OS not just Postgres). I urgently recommend that you make a dump of your data, install something more modern, and reload the database. If your version of Postgres had REINDEX, you might be able to get out from under the immediate problem with that, but REINDEX wasn't there before Postgres 7.0. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1831: plperl gives error after reconnect.
On Sat, Aug 20, 2005 at 12:22:05AM -0400, Tom Lane wrote: > Would anyone like to explain what ::_plperl_to_pg_array is for, and > why it's only created by loose_embedding[] and not strict_embedding[]? loose_embedding[] and strict_embedding[] have several lines in common. Should the common elements be in a separate string or macro so they can be maintained in one place? -- Michael Fuhr ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1831: plperl gives error after reconnect.
Michael Fuhr <[EMAIL PROTECTED]> writes: > loose_embedding[] and strict_embedding[] have several lines in > common. Should the common elements be in a separate string or > macro so they can be maintained in one place? Definitely, assuming you can do it without too much violence to the readability. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] CSV import issue - please help
Dear Postgresql specialists
I would like to seek help with problems I am experiencing with the
COPY command.
We have a user whose 3rd party software exports text data in CSV
format.
The Postgresql import function COPY supports CSV but fails when
importing the data.
I have studied in the Postgresql documentation the specification for
CSV input of the COPY command and found that the data is compliant
with that specification.
In particular, I could confirm that the data uses the same newline
character "\n" for both CSV record termination and new lines within
text.
To eliminate any misunderstandings, I have executed a testcase on
Linux, again exclusively using the Linux "\n" newline character as
follows:
# su postgres
$ psql -d myDB -U postgres
=# CREATE TABLE TEST(FIELD_1 TEXT NOT NULL);
=# INSERT INTO TEST(FIELD_1)VALUES('Hello1 \n\n');
=# INSERT INTO TEST(FIELD_1)VALUES('Hello2');
=# COPY TEST TO '/tmp/TEST.txt' DELIMITER '\t' CSV;
WARNING: CSV fields with embedded linefeed or carriage return
characters might not be able to be reimported
=# DELETE FROM TEST;
DELETE 2
=# COPY TEST FROM '/tmp/TEST.txt' DELIMITER '\t' CSV;
ERROR: unterminated CSV quoted field
CONTEXT: COPY test, line 2: ""
The error messages in the tescase suggest that the implementation does
not agree with the specification in the manual.
I have also verified with other tests that the user's CSV output
conforms with the Postgres specification.
Possibly someone with more in-depth knowledge may have additional
information, e.g. undocumented command parameters, that circumvent
this problem.
The user has only a CSV export function available without any option
to eliminate newline characters from that data.
Unfortunately the user is not in the position to convert the output to
another format or change the software output in any non-standard way.
Any help would be highly appreciated.
Regards
Bernard
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
