creditloss breaks if user has leech/ratio 0 and you set a creditloss

[flasherss]

Describe the bug*
If a user has leech/ratio 0 and you set a creditloss for the group the user is in or that specific user they can't download even though they have leech/ratio 0. If you give them credits then it will work.

To Reproduce
Steps to reproduce the behavior:

1. Change user to ratio 0 and make sure they have 0 credits or negative credits. Ratio: 0.0 Credits: 0B
2. Add to perms config
   creditloss /TEST/* 4 =grp -testuser
3. Login to ftp and try to download something from that specific section under the testuser
4. Error RETR test.sample.mkv
   550 Not enough credits

Expected behavior
Before when using creditloss if a user has leech/ratio 0 it would not affect the user due to them having unlimited credits

DrFTPD

• OS: Debian
• Java version openjdk 15.0.2 2021-01-19
  OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7)
  OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.2+7, mixed mode, sharing)
• DrFTPD version 4.0.7 but I assume has not worked since version 4 came along

[mvangoor]

Hello @flasherss,

I have checked the code and this particular plugin (stats) has not been touched since 3.4.3.

Reading the code it would appear that this "creditloss" config is a global overwrite on the user ratio.

Can you provide more information regarding which version this might have worked differently?

[flasherss]

Hi @mvangoor,

It has been a while since I have used it so not sure when it may of changed so maybe it changed between dr2 and dr 3.
I can't remember if it worked the way I am thinking so it may of been this way always.

I am assuming it was setup to by how glftpd handles it when set to where if a user a ratio 0/leech then they are excluded from the creditloss check since they have unlimited credits

If you look at

drftpd/src/plugins/statistics/src/main/java/org/drftpd/statistics/master/StatsPreHook.java

Line 64 in 84c6cbe

if (userCredits < creditsLoss) {

It says that if a user has ratio 0 then it should allow them unless they have negative credits but it does not currently.

[mvangoor]

Hi @flasherss,

It has been a while, sorry for that...

I am unable to reproduce this on latest master.
Checking code this should guard against your scenario:
https://github.com/drftpd-ng/drftpd/blob/3.4.3/src/plugins/org.drftpd.plugins.stats/src/org/drftpd/plugins/stats/StatsPreHook.java#L51-L53

Please let me know if you can still reproduce this.

[flasherss]

Hi @mvangoor,

I installed DrFTPD 4.0.9 version and java 17 version and it still gives the same error as before.

• testuser shows no credits and the user is ratio 0

200- Username: testuser Created: Wed Nov 09 01:20:46 CET 2022
200- Comment: Added by test Last seen: Wed Nov 09 01:28:51 CET 2022
200- Total logins: 3
200- Idle time: 300 Weekly Allotment: 0
200- Ratio: 0.0 Credits: 0B

• From client as testuser

TYPE I
200 Command okay
PRET RETR testing.sample.mkv
200 OK, planning for upcoming download
PASV
227- Using test for upcoming transfer
227 Entering Passive Mode (x,x,x,x,136,141).
Opening data connection IP: x.x.x.x PORT: xxx
RETR testing.sample.mkv
550 Not enough credits
[i] Failed 1 file(s) and Skipped 0 file(s)

• Java Version
  openjdk 17.0.5 2022-10-18
  OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8)
  OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode, sharing)

[ghost]

Hello @flasherss
Confirmed issue...

[ghost]

add import :

import org.drftpd.master.commands.usermanagement.*;

replace with :

            if (user.getKeyedMap().getObjectFloat(UserManagement.RATIO) == 0) {
                request.setAllowed(true);
            } else if (userCredits < creditsLoss) {
                // this comparison doesn't allow a user with negative credits,
                // but a 0 ratio to download files :)
                request.setAllowed(false);
                request.setDeniedResponse(new CommandResponse(550, "Not enough credits"));
            }

and test again please

[flasherss]

Hi @zc0nf,

Where are you wanting me to add what you said as I am not understanding where you want me to add and replace to test.

Thank you

[mike-codez]

Hi @flasherss,

I tested with a brand new installation added a user gave him ratio 0.
Tried to download a file and it worked fine.

Only scenario I can think of is when you setup creditloss in perms.conf.
This overrides the ratio in the current code base.

Could that be it?

[flasherss]

Hi @mike-codez, That is what I am thinking as that is what is done in step 2 of how to reproduce the issue.

…

On Sat, Nov 4, 2023 at 5:06 PM mike-codez ***@***.***> wrote: Hi @flasherss <https://github.com/flasherss>, I tested with a brand new installation added a user gave him ratio 0. Tried to download a file and it worked fine. Only scenario I can think of is when you setup creditloss in perms.conf. This overrides the ratio in the current code base. Could that be it? — Reply to this email directly, view it on GitHub <#255 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWKSEPG2YRUUORA5APGBNCTYC235DAVCNFSM5H7MU4TKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGM2TMNRQGQ2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mike-codez]

Hello @flasherss,

If you can confirm that you have a creditloss statement in perms.conf, then we can explain it.

The follow-up question is whether this is expected/wanted behaviour, but that is step 2.

[flasherss]

Yes can confirm having creditloss in perms.conf As far as behavior, if using creditloss in perms, then it should not affect ratio 0 users which current state it does.

…

On Mon, Nov 6, 2023, 8:29 AM mike-codez ***@***.***> wrote: Hello @flasherss <https://github.com/flasherss>, If you can confirm that you have a creditloss statement in perms.conf, then we can explain it. The follow-up question is whether this is expected/wanted behaviour, but that is step 2. — Reply to this email directly, view it on GitHub <#255 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWKSEPB4UNST4AW7HF4QPPDYDDX6FAVCNFSM5H7MU4TKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGQ4TKOBXGY2Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mike-codez]

Hello @flasherss,

Thank you for confirming as I do not have that statement in the configurations on my end and therefor the test results differ.

As stated before this is the way creditloss and creditcheck have worked for years in drftpd.

Based on that this is not a bug BUT a "working as designed" kind of thing.

Best way forward would be to provide a config option to change this behaviour so people can influence it.

I'll discuss internally to see what the best course forward actually is.