harddisk filesystem directory separation suggestion
| Project: | JNode Core |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
Hello,
on most operating systems, applications can access any directory existing on an attached (readable) filesystem. An application can also write into different directories and load other applications from different directories and there are concepts like during runtime loaded code like dlls on Windows os.
This issue is to suggest to make applications only see the directory from which they were started and to be able to write only to the directory they were started from except for user files pointed to a different user directory by a user dialogue from an os interface and files requested to be loaded from a user directory in an application via such a user dilaogue from an os interface. This shouldn't affect os calls (an os method can be called which the os has to load from one of its directories first).
Application installation should occur by the os creating a directory for the application and copying all relavant files there.
Benefits:
- (application installation) the user isn't bothered with directories and files of an application, they are unrelevant for him operating the application
- (application installation) applications can be made to install with one command without further interaction
- (application installation) applications don't have knowledge of the os filesystem environment which they don't need
- (only see the applications directory) arbitrary code cannot be loaded, this prevents malware
- (only write to the applications directory) "dll hell" and os interaction problems cannot arise. Note that the shared dll access on Windows is rarely used in fact and shared code is rather small anyway and disk space is hardly an issue nowadays too.
- (user directory) a user only has to bother with one directory (and his created subdirectories) what allows directory display programs and the os to concentrate on their main task: an interface between the "computer" and the users files and applications.
- (user directory) backup only has to worry about one directory (and its subdirectories)
Note that any application would have to be "installed" first so that applications downloaded from the internet to a user directory cannot run havoc on a users directory.
The os is responsible for directory viewability and access control of applications.
Adding to this, an appropriate filesystem could be devised which has all code files marked as non-growable and user files to be growable by a certain percentage based on their current size (arbitray user file size changes could always happen). This prevents disk fragmentation and disk space waste.
Comments?
Best regards,
Lars
- Login to post comments
Some thoughts
I believe Java's package keyword and access modifiers already bundle up a lot of this request into one place.
Each application, plugin, driver, etc, all exists within a package namespace such as org.jnode, com.sun, etc.
These translate into /org/jnode/ and /com/sun/ directories for the classloader and the namespace security feature. Without getting crazy with the Reflections API, this also takes advantage of other language features such as access modifiers.
Sticking with the package tree as a direct map to the filesystem tree also has the advantage of requiring the fewest changes to third-party code, by allowing the system to just use/reuse the developer's existing package tree and statements.
Traditionally, developers were encouraged to develop their own classes within packages that used their own domain names as the filetree/package names, and that would be good to preserve IMO, even if the package is a sourceforge project or whatever. It might be worth extending it to include a user@ as the final part, so that user@domain.com would have a default home package of /com/domain/user/classesgohere
Jarfiles break this to an extent, but Jnode doesn't seem to run stuff from Jarfiles now, so you would have to uncompress them anyway to use them.
This is the scheme I am considering for a Jnode 0.2.6-dev system I am building on an EXT2 disk:
/java/{lang,awt,swing,io,util,net,etc}/classes
/org/jnode/jnode32.gz
/org/jnode/{default,full,test,shell}.jgz
/org/jnode/{core,shell,gui,net,textui,etc}
/org/gnu/classpath/*
/org/gnu/grub/boot/codehere
/com/sun/whatever/
/com/mydomain/mylogin/myownclasses
etc.
This is just for .java sources and .class files.
User home stuff, and shared group filespaces should go elsewhere off of the root tree, IMO.
Just some thoughts I am kicking around...
--
Robert "Exile In Paradise" Murphey
I don't know about package access principles but the idea was...
One facet of the suggestion is that application and os data is separated from the user data. The user and directory display applications (like Explorer on Windows) should never see the directory structure of applications and the os. So why not place all os files into one folder internally? The development view of os files can (and will) have sort of different directories (this can be achieved by having a text file for example which lists which files the development application should group together in its view of the development files) but the physical layout can all be in one directory (I'm a fan of seperating physical data and logical (for humans intended) views on this data).
The file system which guarantees separation can look like this:
-The os boot application is placed contiguously at a fixed never-changing place on the disk.
-The mbr contains a link to this place
-There are 2 main tables: one for applications and one for user files (there are just applications (and their appertaining files) and user files on a computer). For each application the table contains a link to the file table for that application. This file table is all an application can see.
-The position of the main application table is random and gets hardcoded into the boot application on os install. This should ensure that no other application knows where the main application table is and therefore no application can get access to other applications (if they manage to circumvent java os methods which always only show the current applications file table) except for an analysis of the boot application but there may be ways of making extracting this information from the boot application difficult or even hindering access to it.
-user files can be accessed by java os methods which require the user to explicitly choose the files.
I don't know how the package namespace access principles work, but can't any java application call Runtime.getRuntime().load(anyfile) and play with the java.io.File methods (if there is no security manager)?
Lars