Re: Is Unix security really so weak?

In article <87bu7un0ht.fsf_at_erlenstar.demon.co.uk>, Andrew Gierth <andrew_at_erlenstar.demon.co.uk> wrote:
>[bringing in comp.databases.oracle.server]
>
>This started as a security discussion, but the quoted poster has been
>asserting that use of raw devices was somehow essential for Oracle for
>data to be recoverable.
>
>>>>>> "Nick" == Nick Maclaren <nmm1_at_cus.cam.ac.uk> writes:
>
> Nick> I suggest that you learn a little more about the combination of Unix,
> Nick> Oracle, dumping while the system is running, and data recovery. Yes,
> Nick> it will work just fine until there is a crash while it is updating its
> Nick> data - so you shouldn't have a problem, having no data :-)
>
> >> Uh, what do you think that redo logs, fsync(), online backup etc. are all
> >> for?
>
> Nick> I suggest that you look into them a little more closely; especially
> Nick> the conditions that Oracle needs for its recovery to be reliable, and
> Nick> what Unix file systems ACTUALLY do.
>
>I know quite a lot about what Unix file systems actually do, thank you. I do
>not have access to much Oracle information at present (haven't touched it
>since leaving my last job earlier this year), but I can quite categorically
>say that your statements are not backed up by those Oracle manuals that I
>have read. Since you presumably have the information to hand, and I don't,
>perhaps you could detail precisely what conditions you think are applicable?
>
> Nick> A clue: I have used several Unix filesystems where (a) fsync was not
> Nick> available or (b) where it was available but purely decorative. In both
> Nick> cases, later writes could overtake earlier ones (intervening fsync or
> Nick> even close notwithstanding). This is more common than you think.
>
>I am quite aware of that. I am also aware that in the platform-specific
>Oracle documentation for one such system (SCO 3.2v4) there is not the
>slightest hint that using raw devices is anything more than a performance
>issue.

Earlier writes overtaking later writes SHOULD NEVER happen even with buffered I/O. All writes SHOULD go to the same buffer and therefore be time sequenced. I'm not a kernel hack and therefore do not claim to know the details of implementation but if what you are saying is true it is VERY disturbing. Do either of you have some sample code and a list of hardware and software combos that can recreate this problem?

Also is this an issue for UNIX branding (do filesystems have to behave correctly to recieve POSSIX or UNIX certification?

tia

mjr Received on Sat Apr 05 1997 - 00:00:00 CST