ioFTPD v6.1.0 Beta Released

[whocarez2k5]

That broken part you need to skip, i meant with that that i miss configured the server the way i wanted, so i did a clean setup.

That double part, how does io deal with that?

The example says that you can remove that incoming part but in that case you will get double rules/commands!

That registry part, has more to do with ioGUI build in latest io version, and because it's delivered with io now i did mentioned here.

I'm aware that ioGUI isn't needed but it's the simplest way to check if everything works fine.

I'm not gonna go further here with the problems i encounter otherwise i get banned from the forum for cross posting

[ArtX]

Originally Posted by Zer0Racer

This is by design. I take it you haven't read the changelog at all for io 6.x It's designed this way for security reasons. Now l33t h4xXoRs have a hard time fishing for info on which usernames exist etc. And since the logs contain the correct info that only admins should have access to.. isn't that nice?

/ZR

yes and no -- no, cus ioftpd is on a pc that has no net axs - just a home backup server, but i get the point of it, and no i didnt read the changelog - i have add

[Zer0Racer]

Originally Posted by whocarez2k5

That double part, how does io deal with that?

ioFTPD neatly handles multiple lines of settings. It checks the lines top to bottom and acts accordingly. Take the example with the detailed vfs permissions – you have a couple of default rules that basically allows users to upload, download, create dirs etc.

Upload = * * simply means "everywhere" "everyone" is allowed to upload, but at the same time limited by the chmod settings on the existing vfs system. Now, what happens if I put another Upload rule just beneath it? Nothing happens since the first rule applies, everyone everywhere. That rule lets everything slide. So you need to put additional rules above the default rule in order to take advantage of the config's strength.

Example:
Upload = /Incoming/* 1M
Upload = * *

This means that only users with the flag 1 or M can upload to /Incoming but everywhere else is not limited by this rule since it's path specific.

You can but lots and lots of lines there to really tweak your vfs to only allow the actions you've chosen. Btw.. my own ioFTPD.ini has some 30+ lines starting with Upload and it has been working just great for years.

Originally Posted by whocarez2k5

The example says that you can remove that incoming part but in that case you will get double rules/commands!

I'm sure the "remove the incoming" part refers to removing the lines containing /Incoming/*, thus you won't have any duplicates. You're not supposed to just edit out the text "/Incoming/*".

Originally Posted by whocarez2k5

That registry part, has more to do with ioGUI build in latest io version, and because it's delivered with io now i did mentioned here.

I'm aware that ioGUI isn't needed but it's the simplest way to check if everything works fine.

ioGUI is NOT the simplest way to check if everything works. If you want to make sure ioFTPD works, set it up and try to log in with a regular ftp client. And I have to mention (again) that ioGUI really isn't a part of ioFTPD. Yil just chose to put it in the default package to "help" new users.

So my suggestion is, forget about ioGUI for now, set up your ioFTPD so that it works for you on your system. When you get it to work (login, download, upload, fxp, ssl etc.) you can sink your teeth into ioGUI by just making the needed changes in settings.ini and sites.ini to suit your config.. then fire it up.




This is alot of text that might not make you even a little bit smarter. But I've done this for years and I really haven't had any major problems with ioFTPD. It's actually VERY easy once you know the foundation of it – set up the vfs, generate your own ssl cert (optional) make sure you've forwarded/opened (and configured) the correct ports and dataports to the ones you want, then just log in. It's explained in greater detail in the online documentation I wrote back in May 2003 for ioFTPD 4.9.x, and most of it still applies to io 6.x.

/ZR

[Zer0Racer]

Hey Yil.

Got some info that might help tracking down one of those internal bugs that crashes ioFTPD. The last few days I've experienced a handful of crashes directly after issuing ie. MKDIR command after LOGIN. The ioFTPD.log logs the LOGIN event but not NEWDIR. This is the 0x00418d34 crash and the event when I started io again manually.

07-07-2007 16:36:59 LOGIN: "FTP_Service" "***" "***" "***" "*@***"
07-07-2007 16:39:04 START: "PID=5276" "CmdLine="

[18:43:56] [R] MKD ***
[18:43:57] [R] Connection lost: ***

Another time nothing strange happened but one user logged in download some files and ioFTPD crashed the same second the xferlog logged that that user just transferred another file. This last occurance was logged as 0x0042010a in the crash log.

Some info that might be relevant; I hide IPs in xferlog, use SSL, global outbound speedlimit, on OnUploadComplete I use EXEC ZR-Ban, EXEC ioZS, TCL newdir script and TCL nfourl script and PRE mkd I have ZR-Ban and newdir, and on OnFtpLogin I use the script ioActivity to log last logins.

EDIT: I decided to disable the newdir script for now to rule it out.

/ZR

[Yil]

Zero: I went back to the function map and that address is in the ListMergeInfo function which is something I wrote for the new directory listing code. When using merged/raided dirs it sums up the entries from two different directories with the same name into a faked out single entry. This eliminates the old 5.8+ code where you would see dir ABC and then later on another ABC dir (or if you view it sorted two next to each other). Since this should only be called when merging mount points or when you have two directories of the same name beneath those mount points can you confirm you actually are using that feature?

Oops, looks like I use that to fake out the root entry of every directory, but still, would be good to know the types of VFS dirs being used.

[Yil]

First off, I noticed the "symbolic links not showing up" problem a few people have reported. Basically when you create a symlink by converting a directory the link part isn't showing up in listings (but it works!) until you restart the server or the directory is flushed from the cache. It only happens when using the No_SubDir_Sizing option. What's happening here is converting a directory to a symlink just changes the .ioftpd file so the directory timestamp isn't updated and the fake directory entry doesn't know it should update itself.

I've fixed the problem by hunting down and invalidating the fake entry during updates on directories. This should also fix any potential issues with not seeing permission updates as I think that could happen as well.

While playing with this I've also become annoyed at symlinks in general. You manipulate them via "site chattr" but this command allows you to not only modify symlinks but the private flag thus making this command unsuitable for non-trusted users which means most people can't really create them. That's bad, but even worse is the fact that deleting them is hard.

Therefor I'm going to:
1) Create a new site command "site symlink name | target" which will allow users to create a symlink since you can allow more users access to the command. I think I'll also allow a shorthand of just "site target" which will strip off the last component and use that as the local name and in either case the target must actually exist. Using | as the delimiter isn't perfect (it's not a valid windows file character, and perhaps not a unix one either - but it's certainly a tricky one if it is) but it's a whole lot better than a 2 stage command like rename uses or enclosing stuff in quotes...

2) Modify the RMD (remove directory) command to NOT follow symlinks. Currently if you enter the command manually it will try to delete the target directory which will usually just fail since it's not empty, but if it is empty it's probably not what you expected...

3) Modify the DELE command which is what Flash, etc use when you try to delete a symlink to just go ahead and delete the link provided you have permissions on the link itself. No more having to revert the link to a directory and then deleting it. That SUCKS bigtime and of course means nobody without VM flags can actually do it...

There are a few dumb things you can do like turn a populated directory into a symlink via chatter which hides all the files in it but I'm not sure I'll write checks for that since only VM flagged users can use it anyway...

Oh, I think I'm going to add a "site ioversion" command which will print the version of ioFTPD. I'll default it to 1+ users, but just want to make sure nobody knows of a script using it already. I got burned with "site free" once already

[Zer0Racer]

Originally Posted by Yil

Zero: I went back to the function map and that address is in the ListMergeInfo function which is something I wrote for the new directory listing code. When using merged/raided dirs it sums up the entries from two different directories with the same name into a faked out single entry. This eliminates the old 5.8+ code where you would see dir ABC and then later on another ABC dir (or if you view it sorted two next to each other). Since this should only be called when merging mount points or when you have two directories of the same name beneath those mount points can you confirm you actually are using that feature?

Oops, looks like I use that to fake out the root entry of every directory, but still, would be good to know the types of VFS dirs being used.

At the moment I don't use merged directories. Root is a dir containing two symlinks and one empty dir named [sitename], yes including the brackets. That dir is chmodded to 000. The symlinks are updated manually every month or so.

All the other dirs are mounted seperately into that root dir and one or two are mounted with underscore infront of the name in order to be at the top of the dirlist ie. "x:\somedir" mounted as /_archive. Such mount points sometimes also occur as subdirs inside any given dir mounted to root.

And btw I don't use Allowed_Recursive or No_Subdir_Sizing.

Allowed_Recursive       = !*
Hide_Xfer_Host          = True
No_SubDir_Sizing        = False

Hope this helps, and if you need any other info just let me know
/ZR

[Zer0Racer]

Originally Posted by Yil

[...]

While playing with this I've also become annoyed at symlinks in general. You manipulate them via "site chattr" but this command allows you to not only modify symlinks but the private flag thus making this command unsuitable for non-trusted users which means most people can't really create them. That's bad, but even worse is the fact that deleting them is hard.

[...]

Oh, I think I'm going to add a "site ioversion" command which will print the version of ioFTPD. I'll default it to 1+ users, but just want to make sure nobody knows of a script using it already. I got burned with "site free" once already

While you're at it please see if you can come up with a solution for the permissions on private dirs. Currently you have to site chattr +h "dir" "-user -user =group" or use a flag. The permissions seem to be set as string/text and then read. But what happens if you rename a user? When I check the permissions for a private dir it still shows the old username. Maybe the permissions themselves in the .ioftpd file can somehow be bound to the uid but still show the username when you want to view the permissions?

tuff wrote/modified a version script for ioftpd and it works nicely with io 6.x.

proc onsiteversion {} {
  set executable "c:/ioFTPD/system/ioFTPD.exe"
  set filesize [file size $executable]
  set infile [open $executable r]
 seek $infile [expr $filesize - 2]
 set offset [scan [read $infile 1] %c]
 seek $infile [expr $filesize - [expr $offset + 3]]
  set version [read $infile]
 regsub -all {[^\w\d\-]} $version {} version
 set version [string map {-  .} $version]
  close $infile;
  iputs "ioFTPD version: $version"
}
onsiteversion

version = TCL ..\scripts\version\onsiteversion.itcl

/ZR

[Yil]

Zero: The private dir permissions utilize the same routine as all of the .ini file options and thus are just strings that use names instead of id's. I suppose that format could be extended to support id's for users/groups and when valid users/groups are specified they could be resolved and stored that way. I think it's probably far far easier to just use a user flag though. That's especially true since if you add a new user you would be forced to update all the permissions if you specified them individually and that's probably more likely than the user rename issue.

Yea, I append the extra data to executables so tuff's script works That's cool, and mentioning that means I probably should provide a TCL version as well for future use.

VFS: it sounds like you're doing nothing fancy at all. That means the problem won't be found easily as it's more likely memory corruption based rather than a simple programming error in the new code I wrote.

[Zer0Racer]

Originally Posted by Yil

Zero: The private dir permissions utilize the same routine as all of the .ini file options and thus are just strings that use names instead of id's. I suppose that format could be extended to support id's for users/groups and when valid users/groups are specified they could be resolved and stored that way. I think it's probably far far easier to just use a user flag though. That's especially true since if you add a new user you would be forced to update all the permissions if you specified them individually and that's probably more likely than the user rename issue.

Yea, I append the extra data to executables so tuff's script works That's cool, and mentioning that means I probably should provide a TCL version as well for future use.

VFS: it sounds like you're doing nothing fancy at all. That means the problem won't be found easily as it's more likely memory corruption based rather than a simple programming error in the new code I wrote.

Of course using flags is very handy for certain types of private dirs that more than one user has access to. But for scenarios like when you have one private dir (as a subdir) for each user and set the permissions accordingly, just to be extra sure that noone could gain access to something they're not supposed to, making that resolve thing to uid work would greatly improve the flexibility. Just a thought...

Any ideas on how that supposed memory corruption could be tracked down? Maybe a debug version?

/ZR

[BigBoxer]

i have problem with SSL and Windows Vista Home Premium x32, i generate certificate on the machine via ioFTPd with a rsagen command that executes rsa.bat that contains the makecert etc etc command. then i install the certificate to the system. I start ioFTPd and then try to connect and it says
[1] AUTH SSL
[1] 504 AUTH SSL unsupported.

i also tryed to move certificate in different certification archive (in vista there are 3 main certificate archive) but i get always the same message when trying to connect?

anyone solved?

[ArtX]

Yil first time i have had a crash on 6.1.x in a long time but i had one today

Unhandled exception 3221225477 at address 0x20b0bcd8 (0x00000000)
0x00000000 0x0000000c

edit: and another one
Unhandled exception 3221225477 at address 0x20b0b3a7 (0x00000000)
0x00000000 0x00000528

[whocarez2k5]

Originally Posted by BigBoxer

i have problem with SSL and Windows Vista Home Premium x32, i generate certificate on the machine via ioFTPd with a rsagen command that executes rsa.bat that contains the makecert etc etc command. then i install the certificate to the system. I start ioFTPd and then try to connect and it says
[1] AUTH SSL
[1] 504 AUTH SSL unsupported.

i also tryed to move certificate in different certification archive (in vista there are 3 main certificate archive) but i get always the same message when trying to connect?

anyone solved?

Try to reboot your pc.
Worked for me everytime'

p.s.: i probably don't have to say it but ioftpd.ini is modified for ssl?

[Zer0Racer]

Thread closed because 6.2.0 thread is now open where the memory corruption is being debugged.

/ZR