While I do not actively post on this list or contribute to VFS, I have
used VFS extensively and been trying to start on a project that would
both use it and allow me to contribute. I have given a great deal of
thought to the permissions and have a suggestion. There are two primary
types of permissions models that need to be accounted for, and nearly
everything falls under these. There are UNIX type permissions -
user/group/owner and read/write/execute, and there are Access Control
List based systems, which is what Windows, Solaris, and many other
systems (including some Linux versions) implement.
I would implement these as two completely different sets of discoverable
capabilities. A given file or file system type may support neither,
either, or both. Many systems would never support any, Windows would
support ACL style, Linux would support Unix style, and Solaris may
support both.
A Unix style would have to be able to deal with users and groups as
numerics, and possibly provide an interface for resolving those groups
to names where the information can be obtained for the underlying file
system.
An ACL system would also have groups, group membership, users, a set of
distinct assignable rights, etc. ACL is certainly the more complex
system to implement.
The reality does remain however that some level of native interface will
be required for many of these, but that is an implementation detail that
matters for each specific file system and should not prevent adding a
support framework to VFS. While I haven't looked at what the underlying
library support, it occurs to me that a CIFS system might be the ideal
candidate to use for developing the ACL test case as it should be doable
with no native code.
Note that I would put together something to contribute if I had time.
Since I haven't I wanted to at least throw the results of my thoughts
out for discussions since the topic has come up.
Thanks!
Mario Ivankovits wrote:
Hi!
I'm making a prototype of File to VFS adaptor
(http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/util/jio/),
which made me realise that there is no support for setting a bunch of
stuff like read-only, hidden, etc, that a File does...
These limitation are simply due to the restrictions of the most
filesystem libraries, they simply do not provide such a mechanism,
even for local files we have to go the native way to change those
attributes.
2) Deprecate or remove the getters, add a new Service/Action/Operation
that allow to get/set that information.
When we deprecate those methods is another story, but to figure out a
common way how to modify attributes and security constraints will be
the first challange. Implementing such a stuff as
Service/Action/Operation at a first step will be great.
We need to find a way to express the various security systems
linux/windows using one api.
I am currently out of time to think about in detail, but maybe
something like
file owner (with an set of permissions for windows/linux)
file users (other users with special rights - with an set of
permissions representable only for windows)
file usergroups (n groups in windows. only two: group/other in linux)
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
