[EMAIL PROTECTED] wrote
> Thanks for information. But about the conclusion that Unix
> is't unsuited for commercial application I think is a bit more to talk:
>
> I think it is perfect to have this possibility to set control
> on a part of a file, but I think those can't be part of operating system
> while we talk about a large ussable OS. Let me said what I understood then
> show me if I wrong:
> A posibility to set access rights to parts of a file.
> I.e some user should be allowed to read from offset n*0 .. n*100,
> some users to be allowed to write to offsets n*101 .. n*250 etc.
> But what will happend if other database engine use text entrys with
> variable size record? Will be forced to say: Only fixed records databases
> are allowed on that OS?
Not so. What we are saying is that this particular database has
fixed records with certain fields. The software for accessing such
a file is part of the OS-supplied services. Because Unix has
a monolithic kernel, these need to be kernel calls.
If the variable record length file format is implemented as part
of the OS's file system services, then access control can be implemented
by record number.
> Or may need an software tools wich scan for record to be read and verify
> where it is second field on ther record and look for access rights.
> Should be possible, but I think this tosls must be part of database
> engine not on the OS kernel.
No, they can be within the kernel, or in the case of a more modern
OS, within a file system. Unix does not supply any file structure,
except to say that all files are sequential streams of bytes. This
is very different from the elaborate sets of file types and access
methods provided by other OS's. We must always bear in mind that
Unix is an old OS, with a crude design-- a hack. It is extremely
convenient for some applications, but database applications are
not one of these.
I suppose that Alta-Vista is an example of a successful Unix database
application. I am unaware of the nature of the filesystem used with
it. But Alta-Vista does not have much in the way of access-control
requirements.
> On an mainframe with a proprietary OS and wich use only one database
> engine, they can implement as kernel part some security tools, but for
> an OS ussable for everything ....... I think that job can't be performed
> by the OS.
Well, the fact remains that these functions were and are performed
with system level code on other OS's. With Unix, we are too accustomed
to a simple security model, and a file system with no features to
speak of. Our filesystem consists of hierarchicly ordered directories,
and internally unstructured byte stream files. The security model
is (hardware) two rings of privilege, user and kernel, and (software),
root, who can do all, and users and groups, whose access is a
combination of "read","write", and "execute". Design challenge:
design a file in which anyone in the world can read the "employee
name", but no one, (including root), except the supervisor of
accounting, can write the salary field, and that changes to this
field (but not the change itself), will be logged to a file which
only the security operator (again, not root) can read or delete.
Attempted read access of this salary field by anyone except the
accounting supervisor (at any time) or the checkprinting /program/
(on Thursday afternoon), should trigger a security alarm.
We see root as a kind of god, which it is... but root shouldn't be.
System admin is a /clerical/ task. There is no reason for a system
operator to have the ability to access every file on a system in
any way possible. This introduces a single point of security failure,
and is the obvious target of every Unix breakin, and is protected
by a single password. There are ways around this, (sudo), but these
are all add-on kludges, IMO. Security in the form of access control
needs to be a fundamental design criterium, and to be implemented
in the core of the OS. Since Unix is usually implemented as a
monolithic kernel, this is where it belongs -- it has more reason
to be there than some things that are there. It's not for speed or convenience,
but for hardware-protected address spaces. In a microkernel design,
access control can be part of the file-system process.
Unix's simple hardware security model, with only two rings
(kernel-space and user-space), is at the root of the crowded kernel.
Even the x86 processor architecture provides for four rings.
(Similar to VMS and Multics).
The structure and access control of objects can be implemented as
a layer of software and hardware independent of the DB engine that
uses it.
> Did I wrong with something?
Not really. Well, I don't think there is an universal OS.
Dave
--
