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.

Reply via email to