Re: Including PL/PgSQL by default
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: Including PL/PgSQL by default |
| Дата | |
| Msg-id | 900ef770b5f02d013569d7d6e1c2779f@biglumber.com обсуждение исходный текст |
| Ответ на | Re: Including PL/PgSQL by default (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Including PL/PgSQL by default
Re: Including PL/PgSQL by default Re: Including PL/PgSQL by default |
| Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I grow weary of repeating this: it's not about resource consumption, nor > about potential security holes in plpgsql itself. It's about handing > attackers the capability to further exploit *other* security holes. Well, without specific examples, I'm not sure I understand what plpgsql buys you that you could not do other ways (e.g. generate_series() for looping). An earlier thread mentioned someone with access to pg_shadow writing a function to hash random passwords and comparing them, but if someone has access to pg_shadow, surely they can simply download the info to their local box for a more efficient cracking attempt? In any rate, that's not really a security hole, so perhaps a better example exists. There are so many simple ways to "do bad things" /without/ plpgsql, I just don't see how the theoretical harm in it being used as an attack vector even comes close to the benefits of having it installed by default. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200802211227 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAke9tdIACgkQvJuQZxSWSsieowCfQTbmdmGdIJSpWCOU5S2bHSR5 1PgAnjxjOV7Dh1X9nF3pPjDDBosiX0Tx =Z6yR -----END PGP SIGNATURE-----
В списке pgsql-hackers по дате отправления: