> >>> If you want to secure your system against a superuser()-level
> >>> intrusion then you need to secure the unix account, or disable
> >>> creation of C-language and other untrusted languages (at least).
> >>
> >> Very likely --- which is why Magnus' idea of an explicit switch to
> >> prevent superuser filesystem access seems attractive to me. It'd
> >> have to turn off LOAD and creation of new C functions as
> well as COPY
> >> and the other stuff we discussed.
>
> > So would a patch to do this be accepted for 8.1 even though we are
> > past feature freeze?
>
> Given that we don't even have a design for it, I think it's a
> bit late for 8.1 :-(.
>
> Both Bruce and I have way more on our plates than we could
> wish, and the other committers aren't getting a lot done, so
> the originally hoped-for beta date of 1 Aug is looking
> completely out of reach. So adding yet more stuff to the
> queue isn't going to get looked upon with great favor.
That's what I was afraid of. But I certainly understand, you guys
certainly have a lot of work pending.
> > And finally, with something like that in place, would you
> be fine with
> > the file editing functions as they stand (limiting them to the pg
> > directories, as I believe it does)?
>
> I'm OK with them even without the directory limitation as
> long as there's a way to disable them. However, I fear the
> whole thing has to wait for 8.2 at this point.
That would be very bad - considering it just missed 8.0 as well.
How about bolting similar functionality on top of just the new functions
for now, as an extension to that patch, and then externd it to cover the
rest of the functions by 8.2? Considering it'd only tough new code, it
couldn't really affect other parts of the system?
(Yes, I realise it's of course not the number of patches that count, but
the amount of code to review. But it'd be much more localised this way)
//Magnus