OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Dec 12, 2019 11:35 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 1:34 am 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
Has anythone tried to design an OS that offers some level of consistency guarantees in the kernel? Maybe use a light kernel interpreter to verify user-defined constraints in a SQL-like fashion? I'm thinking about files=tables and defining constraints on those tables. Any thoughts on this?


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 2:08 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3593
Location: Chichester, UK
It's not clear what constraints you are referring to here. Perhaps you could amplify somewhat on the nature of the problem?


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 2:23 am 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
Integrity constraints. Like column constraints in SQL. For example a such constraint could force the password hash in /etc/passwd table to be of a certain length and contain only hexdigits.

EDIT:

CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int CHECK (Age>=18)
);

Like Age int CHECK above.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 4:45 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3593
Location: Chichester, UK
I see.

My view that this would be to conflate the purpose of the file system (to organize storage) with - in this case - the purpose of the security system (to determine password policy). I think it better to keep distinct systems separate. This way it's easier to change one without affecting the other. A bit like the difference between HiFi separates and a music centre.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 6:06 am 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
The table storage layout would be in this case the "filesystem" format. Constraints would be stored as resource forks or metadata. Constraints would have to be toggled ON one at a time and it should be possible to turn them OFF. A status report for the current active checks should be available. This way the password policy would be configurable. Highly similar to SQL. Maybe I should write an OS in SQL :lol: At least the userland tools.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 7:11 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 3593
Location: Chichester, UK
I would argue that the job of a filesystem is to manage collections of data (files) without concern of what information is stored in those files. This is the antithesis of SQL, whose job is to manipulate data without caring about how that data is stored.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 11:22 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1521
Location: Athens, GA, USA
farcas82 wrote:
Has anythone tried to design an OS that offers some level of consistency guarantees in the kernel? Maybe use a light kernel interpreter to verify user-defined constraints in a SQL-like fashion? I'm thinking about files=tables and defining constraints on those tables. Any thoughts on this?


Record-structured file systems were actually the norm prior to Unix, especially on IBM mainframes. The problem they have is that they tend not to be as flexible as a stream-oriented file system; you need to define a record type at the OS level for every different file type, and most of the record-structured FSes used in the past didn't make that easy; few if any supported flexible record types to any real degree.

A more modern form is the Object-Oriented file system, of which there have been a few examples, but they tend to have the same problems.

Note that their are special-purpose record-structured file systems for some advanced RDBM systems, which deliberately bypass the general-purpose stream-oriented FS which are the default in most modern systems; Oracle offers one for their mainframe versions, IIUC. These tend to be more for highly-tuned performance in SELECT and UPDATE operations, and are not intended as general-purpose file systems.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 12:25 pm 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
Schol-R-LEA wrote:
The problem they have is that they tend not to be as flexible as a stream-oriented file system; you need to define a record type at the OS level for every different file type, and most of the record-structured FSes used in the past didn't make that easy; few if any supported flexible record types to any real degree.


My idea is to introduce some sort of type-checking in the storage layer. In order to make it harder to mess up the system by mistake. Even if it's less flexible (obviously this is the case here) or harder to use (again obviously true). Sort of like static-typing vs dynamically typed scripting languages. AFAIK statically typed languages are more difficult to use but at the same time less bug prone than dynamic ones. OpenVMS also has a record-oriented FS layer but it;s optional as far as I know.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Fri Mar 22, 2019 2:51 pm 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
Now that I'm thinking more about it there exists another possible architecture. A Makefile-like incremental build system that performs integrity checks when file content is changed. This would require a fast way to detect file changes also possibly the capability to quickly locate changes in a file structure. Manually scanning for changes is rather slow. A record-oriented filesystem could bring a "dirty" flag array for each file. One dirty bit per record.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Sun Mar 24, 2019 12:53 am 
Offline
Member
Member

Joined: Wed Mar 09, 2011 3:55 am
Posts: 335
iansjack wrote:
I see.

My view that this would be to conflate the purpose of the file system (to organize storage) with - in this case - the purpose of the security system (to determine password policy). I think it better to keep distinct systems separate. This way it's easier to change one without affecting the other. A bit like the difference between HiFi separates and a music centre.


I think what the OP is after is having the filesystem structured such that /etc/passwd cannot be written to without the security system validating it for usability, to prevent such silliness as

Code:
# head -c 3000 /dev/urandom > /etc/passwd


A better way, IMHO, would be to allow any given file to have an attribute "editwith" for each file, which, if set, allows editing only with a certain binary. Of course, this is not proof against the sufficiently clueless admin, as the editwith attribute for /etc/passwd could always be changed by root, but even with a record structured filesystem, root could always delete /etc/passwd and create a new file with the same name and a record structure that the security system would choke on.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Mon Mar 25, 2019 7:23 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 162
I've been thinking my system may have multiple storage systemsfor various reasons, but security isn't really one of them. For security, I'm thinking of servers; if a program wants secure data, it has to talk to the server program for that data. This is possible in POSIX, LDAP is one way I know of, see also PAM for general flexibility. I think /etc/passwd can be eliminated, but I'm not sure. (I'm not doing POSIX, no PAM for me. I may use LDAP or my own scheme.) The server program can go on another machine for extra isolation. You'll want secure auth for that, of course. I'm told Kerberos has the right design of token exchange for that, a sysadmin friend says every new auth system either copies Kerberos 5 or has security problems until it's changed to do so. If you're worried about performance, what on Earth are you doing? :) I suppose it might matter if you want to lock down the format of every file on a busy system, but as others have said, that leads to severe flexibility problems.

farcas82 wrote:
Now that I'm thinking more about it there exists another possible architecture. A Makefile-like incremental build system that performs integrity checks when file content is changed. This would require a fast way to detect file changes also possibly the capability to quickly locate changes in a file structure. Manually scanning for changes is rather slow. A record-oriented filesystem could bring a "dirty" flag array for each file. One dirty bit per record.

Perhaps the newly-written data doesn't become visible until it's been scanned. If the data goes via a server program, then it can be verified before it's even written, and only the changed records need be verified. The server may also encrypt the data so no other process can get at it, and I like "editwith" too.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Mon Mar 25, 2019 6:25 pm 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
linguofreak wrote:
iansjack wrote:
I see.

My view that this would be to conflate the purpose of the file system (to organize storage) with - in this case - the purpose of the security system (to determine password policy). I think it better to keep distinct systems separate. This way it's easier to change one without affecting the other. A bit like the difference between HiFi separates and a music centre.


I think what the OP is after is having the filesystem structured such that /etc/passwd cannot be written to without the security system validating it for usability, to prevent such silliness as

Code:
# head -c 3000 /dev/urandom > /etc/passwd


A better way, IMHO, would be to allow any given file to have an attribute "editwith" for each file, which, if set, allows editing only with a certain binary. Of course, this is not proof against the sufficiently clueless admin, as the editwith attribute for /etc/passwd could always be changed by root, but even with a record structured filesystem, root could always delete /etc/passwd and create a new file with the same name and a record structure that the security system would choke on.


Indeed I want to prevent accidental breaking of things. But I don't care much about intentional breaking of things. The user (eventually root) should be able to change any file to any value she wishes. Just add a little bit of checking in order to prevent stupid mistakes like rm . / -rf


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Sun Mar 31, 2019 11:27 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7431
Location: Germany
Enforcing such settings to be changed through specific interfaces only? Akin to e.g. visudo for editing sudo config files. Having those interfaces (API / command line) do the sanity checking, and disallowing "raw" access to the configuration for non-root users?

Just an idea.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Record-oriented I/O for safety purposes
PostPosted: Wed Apr 03, 2019 11:14 pm 
Offline

Joined: Thu Mar 21, 2019 9:55 pm
Posts: 8
Solar wrote:
Enforcing such settings to be changed through specific interfaces only? Akin to e.g. visudo for editing sudo config files. Having those interfaces (API / command line) do the sanity checking, and disallowing "raw" access to the configuration for non-root users?

Just an idea.


It would be really difficult to handle so many interfaces. Because as new versions of the toolbox are deployed, new runtime checks would be added in place. This would make interface documentation hellish.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group