Hi, I think I need to explain it more.
1. Now we get the FileObject using FileSystemManager -> FileSystemView -> FileObject We pass the User object to get the FileSystemView. So API wise (NOT implementation wise), FileObject depends on User. I am not saying that "FileObject should always depend on User". I am saying that API wise FileObject can have the access to User. API supports it. I request you to realize the difference between interface and implementation. 2. If you check different File system API, you will find many similarities. I am including few links for your reference. http://jakarta.apache.org/commons/vfs/apidocs/org/apache/commons/vfs/FileObject.html http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html http://edocs.bea.com/wls/docs81/javadocs/weblogic/io/common/T3File.html http://www.stylusstudio.com/docs/v62/javadoc/com/exln/stylus/io/StylusFile.html In all these, file object has the methods to check different permissions (read, write and delete). So I strongly object to remove these methods from our file object. Then FileSystemSecurityManager is of no use. 3. I oppose infinite number of methods in API. In my opinion it is BAD. It violates the basic API design principles - i) Easy to learn ii) Easy to use, even w/o doc iii) Hard to misuse iv) Easy to read and maintain code that uses it v) Easy to extend vi) Hide as much of the implementation as possible. vii) APIs are written by experts for non-experts It is not granularity, it is messing up the API without gaining anything. 4. "FileSystemManager implements FileSystemSecurityManager" will mess the whole thing further. Thanks, Rana Bhattacharyya --- Sergey Vladimirov <[EMAIL PROTECTED]> wrote: > Hi, > > 1. It is not correct that FileObject should always > depends on User. Even if > we obtain FileObject only from FileSystemView, it > doesn't mean that > FileObject is depends on User. It is just mean that > User can obtain this > FileObject thought FileSystemView. > > That's why methods canRead() and canWrite() should > be moved at least to > FileSystemView, or, that's better, to > FileSystemSecurityManager. > > 2. ftplet or FileSystemSecurityManager? > I prefer to implement FileSystemSecurityManager as > the basis for checks. To > allow distinguish between delete dirs and delete > objects. And it is the > simplest way to override the whole security > subsystem. > > If user want to add some simple checks, then it is > ok to do it with ftplet. > But to override the whole security subsystem it > should be placed in one > component. > > By the way, it is possible that FileSystemManager > implements > FileSystemSecurityManager, and all checks will be > placed in it. > > 3. Simple checks and extended checks. > The graduality of security checks is the good point, > not bad. Dividing all > operation to three categories (read, write, delete) > is just way to simplify > implementation on UNIX-like platform and simplifying > File class. > > But if it is possible to move checks to one > specialized class, then checks > can be and should be grained. > > Sergey > > 2006/5/17, Rana Bhattacharyya <[EMAIL PROTECTED]>: > > > > Hi, > > > > Sorry, I beg to differ. > > > > 1. In my opinion, the API should be as simple as > > possible. Also it should be easy to understand. In > > this case, we are getting FileSystemView by > passing > > User and we are getting FileObject from > > FileSystemView. So the FileObject depends on User > > anyway. How you can say that the FileObject cannot > > depend on User when the underlying API says > otherwise. > > The FileSystemSecurityManager can be a custom API > > developed by the integrator but should not be used > in > > the server. > > > > 2. If you check different java file system APIs, > all > > of them have some commonalities ie. getName(), > > canRead(), canWrite() etc. Why do we need to > change > > this without gaining anything much. > > > > 3. FileSystemSecurityManager will introduce > confusion > > in the API design. If you want to do some custom > > permission checking to append, you can always do > that > > using ftplet. If we want to solve this by > introducting > > FileSystemSecurityManager, we will end up > implementing > > other security check like do I have the permission > to > > read a file from an specified index or can I > delete a > > file at say midnight. We can easily solve these > using > > ftplet. Then why FileSystemSecurityManager? > > > > Thanks, > > Rana Bhattacharyya > > > > > > --- Sergey Vladimirov <[EMAIL PROTECTED]> wrote: > > > > > Rana, > > > > > > First, I want to move all security checks to > > > security manager. As you can > > > see, I add deprecated tag to FileObject methods, > to > > > move them to > > > SecurityManager. So it is only temporary > duplication > > > of functions to > > > simplify changing code. > > > > > > Second, from my point of view, FileObject should > be > > > able to not depends on > > > UserObject. Only FileSystemView should contains > > > reference to UserObject. > > > Does or does not FileObject contain reference to > > > User - is the question of > > > implementation. IMO, implementation would be > much > > > simple, if FileObject > > > doesn't depends on UserObject. > > > > > > And third, the main point. Security system > should be > > > more flexible, than > > > just 3 methods canRead, canWrite, canDelete. > > > > > > Sergey > > > > > > 2006/5/17, Rana Bhattacharyya > <[EMAIL PROTECTED]>: > > > > > > > > Hi, > > > > > > > > Why do you need this. FileObject already > has > > > > canRead(), canWrite(), canDelete() methods. > > > > > > > > FileObject depends on UserObject because the > > > > FileSystemView depends on UserObject. > > > > > > > > FileSystemSecurityManager looks like an > add-hoc > > > > solution for something which already exists. > > > > > > > > Thanks, > > > > Rana Bhattacharyya > > > > > > > > > > > > --- Sergey Vladimirov <[EMAIL PROTECTED]> > wrote: > > > > > > > > > Hi, ftpserver-dev, > > > > > > > > > > By this patch I want to introduce > > > > > FileSystemSecurityManager component. It > > > > > should check all file permissions, and it > should > > > be > > > > > the single place to > > > > > check all rights. > > > > > The reason to introduce so many methods > (instead > > > of > > > > > original hasRead, > > > > > hasWrite, hasDelete) is some application > that > > > > > requires different rights to, > > > > > for example, creating files and creating > > > > > directories. > > > > > > > > > > -- > > > > > Sergey Vladimirov > > > > > > > -- > > > Sergey Vladimirov > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > -- > Sergey Vladimirov > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
