Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Jean-Michel POURE writes: >> It is sometimes tricky for Windows users to install a language remotely on >> a Linux box (no access to createlang and/or no knowledge of handlers). > Why not run createlang on the host that the server runs on? I wasn't able to get excited about that argument either. I believe the primary reason why PL languages aren't installed by default is security considerations: users can easily create denial-of- service conditions if given access to a PL. (Example: write infinitely recursive function, invoke it to cause stack overflow crash in your backend, which forces database-wide restart, thereby negating other people's transactions. Repeat until DBA kicks you off...) A DBA who does want to give access to PL languages by default can easily do so by installing them into template1, whence they'll be automatically duplicated into newly created databases. Perhaps this option needs to be documented more prominently. regards, tom lane
Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?
Tom Lane writes: > I believe the primary reason why PL languages aren't installed by > default is security considerations Well, that argumentation seems to be analogous to giving someone login access on a multiuser computer system but not letting him execute, say, perl because he might write recursive functions with it. Such setups exist (perhaps with something else instead of perl and recursive functions) but they are not the norm and usually fine-tuned by the administrator. We have realized time and time again that giving someone access to a PostgreSQL server is already a security risk. Any person can easily crash the server (select cash_out(2) is prominently documented as doing that) or exhaust time and space resources by writing appropriate queries. Privilege systems do not guard against that. Privilege systems are for guarding against a reasonable user "cheating". Now, if a procedural language is not safe (at least as safe as the rest of the system that's accessible to an ordinary user), then it shouldn't be marked "trusted". Otherwise, the consequence of this chain of arguments is that createlang selectively introduces a security whole into your system. Of course, we may warn, "Be careful when installing procedural languages, because ...". But are users going to be careful? How do they know what kind of care to exercise, and just *how* to do that? No, I don't think this is the ideal situation. I don't want to press for changing it right now because I'm not particularly bothered by it, and the second sentence of the previous paragraph might just be true. In a future life, a privilege system should give finer grained control about access to PLs, but we might want to think about what the default should be. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?
I seem to recall that Oracle has all sorts of fancy resource limits that can be applied to users. If such resource limits were implemented, then maybe the DBA could have the power to limit someone to a maximum of 20% cpu and a few transactions per second or something. Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut > Sent: Wednesday, 10 October 2001 6:36 AM > To: Tom Lane > Cc: Jean-Michel POURE; [EMAIL PROTECTED]; Bruce Momjian; > [EMAIL PROTECTED] > Subject: Re: [HACKERS] What about CREATE OR REPLACE FUNCTION? > > > Tom Lane writes: > > > I believe the primary reason why PL languages aren't installed by > > default is security considerations > > Well, that argumentation seems to be analogous to giving someone login > access on a multiuser computer system but not letting him execute, say, > perl because he might write recursive functions with it. Such setups > exist (perhaps with something else instead of perl and recursive > functions) but they are not the norm and usually fine-tuned by the > administrator. > > We have realized time and time again that giving someone access to a > PostgreSQL server is already a security risk. Any person can easily crash > the server (select cash_out(2) is prominently documented as doing that) or > exhaust time and space resources by writing appropriate queries. > Privilege systems do not guard against that. Privilege systems are for > guarding against a reasonable user "cheating". > > Now, if a procedural language is not safe (at least as safe as the rest of > the system that's accessible to an ordinary user), then it shouldn't be > marked "trusted". Otherwise, the consequence of this chain of arguments > is that createlang selectively introduces a security whole into your > system. Of course, we may warn, "Be careful when installing procedural > languages, because ...". But are users going to be careful? How do they > know what kind of care to exercise, and just *how* to do that? > > No, I don't think this is the ideal situation. I don't want to press for > changing it right now because I'm not particularly bothered by it, and the > second sentence of the previous paragraph might just be true. In a future > life, a privilege system should give finer grained control about access to > PLs, but we might want to think about what the default should be. > > -- > Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] >
pgAdmin II v1.1.59 Preview Release
I have just uploaded pgAdmin II v1.1.59 to http://pgadmin.postgresql.org. pgAdmin II is a comprehensive database design and management tool for Win32 platforms, for use with PostgreSQL 7.1+. This is another Preview/Beta release - any comments of bug reports are welcome of course. Changes: - Added comprehensive Revision Control system with undelete & rollback support. - Added support for PostgreSQL 7.2 OID-less tables. - Added support for PostgreSQL 7.2 Encrypted passwords. - Functions can now be editted with PostgreSQL 7.2+. - The Master Connection Database can now be changed if template1 is not available. - Fixed a bug in the SQL generation of tables with char columns. - Unavailable menu options/buttons are now disabled instead of hidden. - Added a Database Publishing Wizard that publishes from staging to production servers. Regards, Dave. -- Dave Page ([EMAIL PROTECTED]) http://pgadmin.postgresql.org/
Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?
Jean-Michel POURE writes: > It is sometimes tricky for Windows users to install a language remotely on > a Linux box (no access to createlang and/or no knowledge of handlers). Why not run createlang on the host that the server runs on? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
