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
