Problem with UID 0, GID 0 and '(null)'

[Zer0Racer]

ioFTPD v4.1.0 + ioFTPDex.exe
Win2K Pro SP3

I think I've found a problem with user (uid 0) and possibly users in group with gid 0. Seems they are treated as 'nobody' or 'null'.

It started when I checked some stats. The username for 0:0 did not show in the stats listing:
200-| 01 | zer0racer @ crew | 954.6 |
200-| 04 | @ ioftpd | 0.0 |

And all folders in VFS owned by 0:0 is now owned by 'nobody'.
SITE CHOWN ioftpd temp
200 CHOWN command successful.
But still owned by 'nobody'.


And I suspect there is a connection to another strange error I got the other day. First I did a 'site who' and noone showed up (not even me). And there was another user downloading. Only who header and footer were displayed. I decided to logout. ioFTPD.log:
02-11-2003 10:11:02 LOGOUT: "FTP_Service" "" "crew" "siteop" "Zer0@217.210.127.169"
Looks like the username got a 'null' value here too. This problem doesn't appear instantly. This was after ioFTPD had been running for several hours, even a day or two.

And then restarted ioFTPD. The logout below was logged in ioFTPD.log:
02-11-2003 10:19:18 LOGOUT: "FTP_Service" "" "ind" "No Tagline Set" "*@[censored]"
This confirms that another user was logged in at the time.

Prior to that my Error.log showed alot of lines where a user was denied login due to lack of privileges, even if my services config allows login for all users '*'.


/Zer0Racer

[Zer0Racer]

When I try to login with user who has uid:gid 0:0 I get this in Error.log:
02-12-2003 11:13:42 Host 'Zer0@217.210.127.169' did not match any of user '(null)' allowed hosts.
If my memory serves me right, this is an error a few guys have been asking about on efnet.

This user has IP *@127.0.0.1. So I tried to login to loopback.
02-12-2003 11:40:51 LOGIN: "FTP_Service" "(null)" "ioftpd" "0" "Zer0@127.0.0.1
ioFTPDex.exe crashed.

The standard ioFTPD.exe for v4.1.0 doesn't crash. Edit: Might crash anyway cause this problem only seems to appear after a couple of hours uptime.
02-12-2003 11:44:31 LOGIN: "FTP_Service" "ioftpd" "ioftpd" "0" "Zer0@127.0.0.1"
VFS shows correct owner.
Stats work too.
200-| 01 | zer0racer @ crew | 954.6 |
200-| 04 | ioftpd @ ioftpd | 0.0 |

[darkone]

I'm not sure if this bug is fixed in next version (but atleast I cannot find any way to replicate it myself... there's been tons of changes in login procedures again)

[Zer0Racer]

This problem occurs in 4.5.4 as well.

Owner of vfs showing up as 'nobody' in group ioftpd and %[$user] doesn't show at all for user 0:0 when doing site uinfo or checking stats etc.

[chuddy]

Hi,


I had same symptoms with UID:GID 0:0. Default ioFTPD account caused (i think) my crashes, same for users in GID:0.
Several times before the crash when i was doing a !who it was showing me most of my users in GID:0 as nobody group (in 4.1.5 and 4.5.4).
Another thing was when i did a !users, it was showing me multiple ioFTPD accounts (?!?) and then it crashed a few after that (this one was observed in 4.1.5 only).

My only try was to delete UID:0 account et GID:0 group. Now io runs for 36h without crashing wich is a record...let's cross my fingers

[darkone]

What do you mean with !who? Does your botscript execute external command to determinate who is online, or logs into site via ftp/telnet and issues 'who/site who'? Anyways.. I haven't managed to cause buffer under/overrun since 4.5.4 (debugger spots such thing usually instantly)

[chuddy]

To be clearier !who was an abusive lingo of my part, in fact i did a 'site who' command. I don't think my bug is relative to 'site who' command, i just observed strange status in user list by a who command. I feel like with time, users or file system is alterate, dunno why cause if it was users file or filesystem it should reproduce same thing after a restart of io but no...it happens with time (few hours), that's why i call it an alteration.
Now that no GID:UID 0:0 exists anymore it seems to be better but only time will tell it.

Another bug i already talk about is the rehash command that freeze new login...all that happens on NT4 Srv SP6a.
I guess i should try to reproduce my installation on a similar NT4 box to see what's happen.

[darkone]

I think I managed to locate cause for this.. remains to be seen.