Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Attached patch implements this proposal, including documentation
changes. I'll work separately on the back-branch version.
Any comments/objections?
Looks OK in a fast scan, except that you are not following the message
style guidelines
Joe Conway wrote:
I'm working on the back branch solution now.
Attached is for back-patching. I left in the SECURITY DEFINER functions
and dblink doc changes -- even though they may not do existing
installations much good, I think there will still be enough new 8.2.x
installations for a whi
I wrote:
> What I'm inclined to propose is that we just remove the
> pgstat_drop_relation() call from smgr_internal_unlink, and rely entirely
> on VACUUM to clean out dead entries in the pgstats data.
On checking the CVS history, that in fact is how the code worked before
8.1.3, when I introduced
Magnus Hagander wrote:
> > Anyway. I'm not sure it matters enough to change it on Unix... It's not
> > like it hasn't worked well for many years ;-)
>
> I've applied this. I didn't include your changes to clean.bat, because
> clean really should clean up everything ;-) This should fix building fo
"Joe Conway" <[EMAIL PROTECTED]> writes:
> If there are no objections I'll commit this later today.
My objection is that I think we should still revoke access for non-superuser
by default. The patch makes granting execute reasonable for most users but
nonetheless it shouldn't be the default.
Bei
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > If there are no objections I'll commit this later today.
>
> My objection is that I think we should still revoke access for non-superuser
> by default. The patch makes granting execute reasonable for most use
"Stephen Frost" <[EMAIL PROTECTED]> writes:
>> Being able to connect to a postgres server shouldn't mean being able to open
>> tcp connections *from* that server to arbitrary other host/ports. Consider
>> for
>> example that it would allow a user to perform a port scan from inside your
>> network
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> Actually from a security point of view revoking public execute is pretty much
> the same as making a function super-user-only. The only difference is how much
> of a hassle it is for the super-user to grant access. Perhaps we should
> reconsider whether
Gregory Stark <[EMAIL PROTECTED]> writes:
> My objection is that I think we should still revoke access for non-superuser
> by default. The patch makes granting execute reasonable for most users but
> nonetheless it shouldn't be the default.
> Being able to connect to a postgres server shouldn't me
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
My objection is that I think we should still revoke access for non-superuser
by default. The patch makes granting execute reasonable for most users but
nonetheless it shouldn't be the default.
Being able to connect to a postgres server
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> My objection is that I think we should still revoke access for non-superuser
>> by default. The patch makes granting execute reasonable for most users but
>> nonetheless it shouldn't be the default.
>
>> Being ab
Gregory Stark wrote:
Consider a scenario like "package uses dblink". Sysadmin follows
instructions for package and installs dblink. Now package 's
documentation isn't going to explain the second-order effects and discuss
restricting who has access to dblink. The sysadmin has no particular inter
* Joe Conway ([EMAIL PROTECTED]) wrote:
> If you are going to argue that we should revoke access for non-superusers
> by default for dblink, then you are also arguing that we should do the same
> for every function created with any untrusted language.
Uh, no, one doesn't imply the other. It doe
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
No, it doesn't... Said arbitrary function in y, in untrusted language
z, could be perfectly safe for users to call. Being written in an
untrusted language has got
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Agreed.
>
> If you are going to argue that we should revoke access for non-superusers by
> default for dblink, then you are also arguing that we should do the same for
> every function created with any untrusted language.
Only if the function created use
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
No, it doesn't... Said arbitrary function in y, in untrusted language
z, could be perfectly safe for users to call.
^
*Could* be. Bu
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> No, it doesn't... Said arbitrary function in y, in untrusted language
>> z, could be perfectly safe for users to call.
> ^
> *Could* be. But we just said that the admin was not interested in reading
> the documentation, an
"Joe Conway" <[EMAIL PROTECTED]> writes:
> See my last email...
>
> Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
Well arbitrary function may or may not actually do anything that needs to be
restricted.
If it does then yes the same concerns arise an
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > Consider a scenario like "package uses > untrusted language z>". Exact same concerns arise.
>
> Well arbitrary function may or may not actually do anything that needs to be
> restricted.
>
> If it does the
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
Sure it matters. A function written in a trusted language is known to be
safe, a priori. A function written in an untrusted language has no such
guarantees, and therefore has to be assumed unsafe unless carefully proved
otherwise.
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> I see.. So all the functions in untrusted languages that come with PG
>> initially should be checked over by every sysadmin when installing PG
>> every time... And the same for PostGIS, and all of the PL's that use
>> untrusted lan
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Stephen Frost wrote:
>
>> I see.. So all the functions in untrusted languages that come with PG
>> initially should be checked over by every sysadmin when installing PG
>> every time... And the same for PostGIS, and all of the PL's that use
>> untrusted
22 matches
Mail list logo
