FXP denial, group changing, etc

[Yil]

First off, this is by far the most customizable, configurable, lightweight, and just plain kickass ftp server I've used. But I suppose everyone already here knows that :)

There are so far 3 things I haven't really been able to figure out.

1) While there is a chown and a chmod command I can't seem to find a way to change the GROUP of a directory or file. This is particularly annoying since I figured if there wasn't a command to change it that it would track the group of the new owner if changed via chown. But that doesn't work either...


2) There is currently NO WAY to grant or deny FXP permissions to a folder/file based on a users group, flags, or name. It's either on or off for everyone. FXP is perhaps a special case since the other transfer related permissions are usually broadly specified and individual file and folder filesystem permissions are used for fine grained control. Thus I think instead of upload having an F/f flag, you should simply create a new FXPsend and FXPreceive keywords (eliminates the upload/download confusion). Thus instead of

Download = * 1MV3YZFf

you would have

Download = * 1MV3YZ
FXPsend = * 1MV3

thus denying FXP downloading to anyone who isn't flagged 1mv3.


3) In order to prevent idling for some users I'm using
noop = !Z *
but it's sorta annoying to see those command not understood messages. Perhaps instead you could add a "noidle" keyword. You could then improve the logic so that people issuing random and pointless noops, pwd, etc could all be ignored when calculating when to apply the idle timelimit...



My initial feedback from playing with it for a few days goes as follows:

1) I'm an old unix type so I don't mind editing config files by hand, but I'd really bundle something like ioGUI with some extra functionality with the product.

2) Since a lot of subtle VFS, permissions, etc issues creep up and bite people or just confound newer users, I'd think about a new site command to show the applicable rules for the specified file or directory would be very useful and rather straighforward. A script, addon gui, etc could then expand the groups, users, etc to highlight which ones have access to do what. I could see that as very powerful. Of course such a script COULD just read the files for themselves, but that doesn't mean it's being processed that way :)

3) I've used srvany to install ioftpd as a service, but it's only a sorta fix since it doesn't gracefully shutdown ioftpd nor does it catch when ioftpd crashes. I'd really provide a simple but proper services wrapper.


-Yil

[darkone]

Originally posted by Yil
[B]First off, this is by far the most customizable, configurable, lightweight, and just plain kickass ftp server I've used. But I suppose everyone already here knows that :)

There are so far 3 things I haven't really been able to figure out.

1) While there is a chown and a chmod command I can't seem to find a way to change the GROUP of a directory or file. This is particularly annoying since I figured if there wasn't a command to change it that it would track the group of the new owner if changed via chown. But that doesn't work either...


Try: "SITE CHOWN :GROUP <directory>" - remember that ':'.


2) There is currently NO WAY to grant or deny FXP permissions to a folder/file based on a users group, flags, or name. It's either on or off for everyone. FXP is perhaps a special case since the other transfer related permissions are usually broadly specified and individual file and folder filesystem permissions are used for fine grained control. Thus I think instead of upload having an F/f flag, you should simply create a new FXPsend and FXPreceive keywords (eliminates the upload/download confusion). Thus instead of

Download = * 1MV3YZFf

you would have

Download = * 1MV3YZ
FXPsend = * 1MV3

thus denying FXP downloading to anyone who isn't flagged 1mv3.


I'm not convinced enough to hardcode such feature. It is something that is certainly possible for module to do in next io.


3) In order to prevent idling for some users I'm using
noop = !Z *
but it's sorta annoying to see those command not understood messages. Perhaps instead you could add a "noidle" keyword. You could then improve the logic so that people issuing random and pointless noops, pwd, etc could all be ignored when calculating when to apply the idle timelimit...


NOOP stands for NO OPERATION. You can write PRE NOOP script that outputs non-error message, but returns with non-zero exit value. However, it is likely that users will start using other commands (PWD, CWD, ...) for keeping their connection alive.



My initial feedback from playing with it for a few days goes as follows:

1) I'm an old unix type so I don't mind editing config files by hand, but I'd really bundle something like ioGUI with some extra functionality with the product.


Next io comes with php-based web-UI.


2) Since a lot of subtle VFS, permissions, etc issues creep up and bite people or just confound newer users, I'd think about a new site command to show the applicable rules for the specified file or directory would be very useful and rather straighforward. A script, addon gui, etc could then expand the groups, users, etc to highlight which ones have access to do what. I could see that as very powerful. Of course such a script COULD just read the files for themselves, but that doesn't mean it's being processed that way :)


I like this idea, however it will only work for the hardcoded checks/functions - so it might be smart to write it as script that supports extensions.


3) I've used srvany to install ioftpd as a service, but it's only a sorta fix since it doesn't gracefully shutdown ioftpd nor does it catch when ioftpd crashes. I'd really provide a simple but proper services wrapper.


Again, next io will run only as NT-service. There is no estimate when next versio is done (@ beta/final), should be sometime this summer though.

[Harm]

Originally posted by Yil

3) In order to prevent idling for some users I'm using
noop = !Z *
but it's sorta annoying to see those command not understood messages. Perhaps instead you could add a "noidle" keyword. You could then improve the logic so that people issuing random and pointless noops, pwd, etc could all be ignored when calculating when to apply the idle timelimit...

Actually, I'm using a script that detects all the known idle commands and kicks the user when too many of those have been used. There are no error messages, the user is only disconnected after some time. It's still not perfect and I won't make it public before the .ioFTPD files are fixed since it uses chattr to store the counters, but I would appreciate your feedback on this.
What idle commands have you noticed ? At the moment I'm checking NOOP, LIST (if it's issued from the same directory multiple times), PWD (in the same directory too) and CWD . (the dot is important) but I'm sure there are others.

[Yil]

Try: "SITE CHOWN :GROUP <directory>" - remember that ':'.

Works great! I'm pretty sure I searched all the docs and the site command documentation before asking as well as searching forum, so perhaps it might need to be documented somewhere.


You can write PRE NOOP script that outputs non-error message, but returns with non-zero exit value. However, it is likely that users will start using other commands (PWD, CWD, ...) for keeping their connection alive.

The whole idea behind a builtin "noidle" instead of just unallowing NOOP was to catch all the cwd ., relists, etc as well at some point and handle them. I was looking for a builtin version of what Harm is suggesting.

Harm: That's basically what I've seen so far. Those are the options available in FlashFXP as well so that would catch 90%+ of my users right there! Let me know when you put your script out :)


Speaking of feature requests :)

1) Would it be possible to have a "user log" or "detailed log" or "verbose log" file option somewhere? I.e. everything from the client and server logged to a file for debugging? Could be username+unique_id or something and dumped in the "log/verbose" directory... Great way to make sure everything working as intended and to verify mirroring scripts, etc are doing what they are supposed to. Could also be used to collect statistics later on :)

2) Oh and the FEAT command would be nice :)

-Yil