It was 12/01/2006 05:10, when Rana Bhattacharyya wrote: > I completely agree with you. In fact this is the > reason I have hardcoded user and group names in our > FileObject implementations.
Something else to consider, because if you add support for changing owner, group and permissions, then you need the ability to find out what the current settings are in order that they can be displayed in the file listing. Already the hasReadPermission() and hasWritePermission() methods are used which effect the permissions displayed based on what they return, but only for the owner. That is, if both return true, then the mode is -rw-------. If "site chmod" is supported, then additional methods would be required to get the read/write permission for group and other, which would only mean something on UNIX. Otherwise you would not display the correct permissions. > May be one thing we can do > is to add few methods like changeOwner() and > changeGroup() in FileObject interface. It will return > true if success. So the current implementations will > return false. If the user wants to use a new file > system manager which will use JNI, these methods can > be overwritten. It sounds like a reasonable solution, if you had to do it. The problem here is balancing a wealth of features and configurability against security. On a UNIX host, in order to listen to port 21 the server is already going to be run as the root user. When a user logs in, the thread doesn't/can't give up rights and run as that actual user on the system, which is what other servers written in C would do as each child process is forked. As such, the user actions have an elevated level of priviledge. When logged in normally to a UNIX host, only the superuser has the rights to change the owner of a file, local users can not do this. So allowing them to do so via the FTP server is, well, wrong IMO. In the proposed changeOwner() etc, I would add big disclaimers about the security implications of implementing such methods. At the end of the day, they are not standard FTP commands. - Dave.
