providing views with vfs

[pradeep]

I like to provide views for the filesystem. for example seperate (db )file is maintained to store the whole access and control security for each and every individual file. Though it wastes lot of secondary memory, it's fine for me. so that fat32,ntfs all have same type of security mechanisms. This is an example for a view. This type of views should be able to be plugged into the file system design. Each and every user might want to provide himself a different type of access and control mechanism for the files. He might provide this type of views for fat32 alone or anything he wants. If he wants to provide views for fat32, he requests to register a new view(vfs) for fat32. so that any request to fat32 is passed thorugh this new view. So that he can control the read and write requests for his requirement. This type of views can be plugged into current file system interface thorugh seperate system calls. Does this makes any sense? It seems possible to implement it. But a lot of unnecessary overhead is required.

[Candy]

I like to provide views for the filesystem. for example seperate (db )file is maintained to store the whole access and control security for each and every individual file. Though it wastes lot of secondary memory, it's fine for me. so that fat32,ntfs all have same type of security mechanisms.

Fat32 doesn't have any security. NTFS has a lot of security. How are you going to match them up? Limit FAT32? Ignore NTFS security?

This is an example for a view. This type of views should be able to be plugged into the file system design. Each and every user might want to provide himself a different type of access and control mechanism for the files. He might provide this type of views for fat32 alone or anything he wants. If he wants to provide views for fat32, he requests to register a new view(vfs) for fat32. so that any request to fat32 is passed thorugh this new view. So that he can control the read and write requests for his requirement. This type of views can be plugged into current file system interface thorugh seperate system calls. Does this makes any sense? It seems possible to implement it. But a lot of unnecessary overhead is required.

It's kind of pointless to make all adjust to one filesystem. The common way to make this work decently is to make one of your own file system views which encapsulates all the others, and to create a filesystem that describes your toplevel file system view. That's then your native FS.

The toplevel one usually has access control and so on.

[pradeep]

The vfs will be providing an interface to all other underlying vfs. i.e there are multiple vfs such as proc in linux,devfs etc. I am not going to consider about the security in fat32 or ntfs. Every file is going to have access and control mechanism in seperate database file. So you need not care about the security features in ntfs. (i.e) ntfs security features doesn't apply here. They are supported only for compatibility with existing file system. The view should be pluggable at any point in the tree. The view may apply to only devfs so that you can't access cdrom. yes it's possible without this view also. But having a view you can disallow any particular user in the group to not access the cdrom but other group members can. It all depends on the users (but yes they have to write a driver for this too). ;D

to create a filesystem that describes your toplevel file system view.

My point here is to provide views for each and every file system (may be for devfs too). Users shouldn't be limited by the toplevel fs access and control mechanism. The view may be applied for particular user only and other users may have different views. So that each and every user might have different view. By allowing more than one view for a particular file system you can implement strange access and control mechanism. for example a group view is first applied then it undergoes through particular user view. You not necessarily provide security mechanism here. You can do manything you want.

[Candy]

sounds like ACL's. Did you search them before you wrote this idea out?

[pradeep]

Definitely this is not my idea, this has been implemented on some systems, i am not quite sure in which OS it is. My idea is just to extend this so that we can provide a view for every fs and every user should have different views. Since i have now only started vfs (after very hard struggle to find information about vfs on net) I don't want to have a redesign on vfs, so i am thinking about every possibilities. How you are associating this text with AccessControlList's? I done a search for it. But the results are odd? So candy could you please explain it. Or some pointers to ACL's having information about views will be helpful?

[Pype.Clicker]

What somehow trouble me with your "view"s is the meaning of having the user deciding of everything. I mean, usually the end-user cannot decide whether he gets access or not: the sysadmin does.

I do agree that it could make sense to have an external file giving the 'mappings' between the access rights and ownership of an 'alien' filesystem and the 'native' one (like only 'root' can modify files from 'Owner' in NTFS and that user jsmith is used as owner of 'Documents of John Smith', but i'm unsure about "every single file" approach ...

One of my concerns being "what do you do with 'new' files on the alien filesystem ? Those for which there's no entry yet in the database ?

[pradeep]

@Pype: It was just an example of one view. My concern is about views and not how it is implemented. The views are like drivers. The Admin is to create them and he may apply to any user he wants or a group. When loading an user account his views are also loaded. For example the views may provide a single file as a hard disk for that user (or anything possible)It's some what harder to implement.

[Pype.Clicker]

well, i'd you should consolidate the bases of your 'view' system. Find concrete examples of how it will be used by the user, what it implies, etc. Atm, it's just a confusing word that somehow reminds me of databases and SNMP lectures, but leaves me clueless of what you're actually trying to achieve (and reading your replies to Candy's comments gives me the feeling i'm not the only one to be confused here ...)

[pradeep]

Views are nothing but a virtual file system which will be implemented over other file system. So before the requests are being passed to the lower file system interface such as fat32 or devfs the requests are handled by the views. So we could provide access and security mechanisms to the underlying file system. I gave the name views to this virtual file system, because it is different for each and every users of the system. So it should be maintained seperate for different users. Still confused?

[Candy]

By Beyond Infinity, actually. Post fits in this thread, but is also starter post for new thread.
------------------

That's a virtual file system.

For me, a view is a virtual table in any RDBMS which permits to give out special data without having the user know the pecularities behind (complicated select with outer join and four other tables involved) - in Oracle or Informix, Views which hide away sophisticated select statements are far more performant than the statement issued directly from the requesting application for the views are kinda precompiled.

But, I Have to stress this again, views have nothing to do with file system abstraction. I ask you not to mix up database terms with file system stuff. Else no one knows what the heck we are talking about.

Design a virtual file system which hooks in the underlying implementations without bothering with implementation specifics (which belong to the fs drivers).

Take a pencil, a rubber and a sheet of paper and do some design work. That's where engineering happens mostatime. In /dev/brain and with pen and paper.

Stay safe & sorry for the rant. I'm in a mood for it today.

PS: I know it's not the place to show off with something, but recently I've managed to get a C on a maths exam.

[Candy]

New thread was moved to General Programming since it is about databases.