Whitelist removal not always working

[FlooferDoofer]

Three names remain on the whitelist in /var/openebs/local/pvc-cb83e64e-896b-4401-b4ca-5958321db183/plugins/BungeeSafeguard/config.yml after removal via in game command. I have not manually removed these names or touched the list in any way since I noticed this issue.

When trying to use /whitelist remove [name] again it gives either a confirmation that they are no longer on the list (which they are): '[name] [UUID] is not in whitelist'

or an error: 'Failed to remove [name] from whitelist: java.io.FileNotFoundException: plugins/BungeeSafeguard/config.yml (Permission denied)'

It concerns the following UUIDs / playernames and removal dates:

• 0f3175cf-1158-4b48-9a26-4a81c1a17c33 / LSniyPunk @ February 26th
• 658a0066-e63f-49cf-a9ef-a7c7328e0232 / dotterel_ @ February12th
• 067a8794-4fb5-485d-be00-d4dfa57e73d6 / ADhockey66 @ March 24th

[ChipWolf]

Perhaps the directory just needs chown -R 1000:2000 Permission denied just means the user doesn't have the permissions set on the file

[ChipWolf]

If the command returns they're not in the whitelist, the plugin is likely reading the list into memory and making modifications to what it holds in memory & reporting success before committing it to disk. In doing so, not surfacing the issue to the user. Perhaps @Luluno01 can chime in on this?

[Luluno01]

If the command returns they're not in the whitelist, the plugin is likely reading the list into memory and making modifications to what it holds in memory & reporting success before committing it to disk. In doing so, not surfacing the issue to the user. Perhaps @Luluno01 can chime in on this?

Yes, the plugin maintains a copy of the whole list in memory and only commits changes to the disk after it changed the list in memory.

@FlooferDoofer mentioned when issuing /whilelist remove [name], there are two kinds of outputs. If I am right, you must have got the Failed to remove [name] from whitelist: java.io.FileNotFoundException: plugins/BungeeSafeguard/config.yml (Permission denied) error on the first attempt, and then [name] [UUID] is not in whitelist on the second attempt. This is because on the first attempt, the plugin first removed the players from the list in memory, and then it failed to save the changes - without rolling back the changes made in memory. Therefore on the second attempt, it detected the players had already been removed.

So the first step to solve this issue is to figure out why it fails to save the changes. Given that I have no idea what this repo is, I would like to turn to @ChipWolf for help XD.

Btw, BungeeSafeguard gets the File object of the config file via bukkit API, so I guess it was writing to the right path but somehow the config file has been removed.

[bloodycoffin]

Config file is there with the whitelisted members - chown to 1000:2000 - will probably first need a reboot before that is processed @ChipWolf let me know if you can think of anything else I can check based on Luluno01's suggestion as for now it seems fine The error messages only started after our last maintenance where we tested the new backup solution and restored from backup - maybe something went wrong here?

[bloodycoffin]

Adding people now also doesn't save them permanently, so we have a general problem with the whitelist @ChipWolf this is now a high priority as it is scaring people off thinking they have been banned when they have just joined and people that have been banned that still have access

[Luluno01]

Adding people now also doesn't save them permanently, so we have a general problem with the whitelist @ChipWolf this is now a high priority as it is scaring people off thinking they have been banned when they have just joined and people that have been banned that still have access

My contingency measurement for this is to always make sure the changes in memory are made - even if they failed to persist. You can verify this via the command /bsg dump to checkout the in memory states. That said, you should still fix the file system problem as the lists are not persisted to the disk in your case.

[FlooferDoofer]

Added 2 new players to whitelist yesterday via /whitelist add [name]. This also shows an error after giving a confirmation.

Then today we needed to unwhitelist 2 players and the players we added yesterday got removed instead.

Attempted to manually remove these players from the config.yml and then test if it would persist after a proxy reboot. It restored the removed players' UUID instead. (Luckily it kept the new additions).

Decided to ban players we want to unwhitelist until whitelist issue is resolved. So while still a high priority, we do have a way of restricting access when needed.

[Luluno01]

Added 2 new players to whitelist yesterday via /whitelist add [name]. This also shows an error after giving a confirmation.

Then today we needed to unwhitelist 2 players and the players we added yesterday got removed instead.

Attempted to manually remove these players from the config.yml and then test if it would persist after a proxy reboot. It restored the removed players' UUID instead. (Luckily it kept the new additions).

Decided to ban players we want to unwhitelist until whitelist issue is resolved. So while still a high priority, we do have a way of restricting access when needed.

Considering all your observations, I now highly suspect that your file system (or the sandbox layer) synchronization mechanism (if you do have one) is broken or at least has an unexpectedly high latency.

Let's denote your initial version of the config file as v0. This is my guess:

Observation 1

Added 2 new players to whitelist yesterday via /whitelist add [name]. This also shows an error after giving a confirmation.

👆 Config file is removed or the plugin has no write access to it. Although the runtime throws an I/O exception, a v1 config file was produced somewhere in your system, but not yet visible to you.

Observation 2

Then today we needed to unwhitelist 2 players and the players we added yesterday got removed instead.

👆 The 2 players you wanted to unwhitelist are removed in memory. At the same time, you were checking the v0 config file, so it looks like the players you added yesterday were "removed". At this point, a v2 config file should have been produced.

Observation 3

Attempted to manually remove these players from the config.yml and then test if it would persist after a proxy reboot. It restored the removed players' UUID instead. (Luckily it kept the new additions).

("the new additions" is a little bit ambiguous here. I will take it as the 2 players you added at the very beginning.)

👆 After the reboot, the v1 config file was finally synchronized to the disk and visible to you (and the plugin). Hence the 2 players were in the list and no one was removed.

Conclusion

So far I believe your issue has nothing to do with my plugin. You should also check if the v2 config file is now taking effect by checking both its content on the file system, and plugin dump.

[bloodycoffin]

chown 1000:2000 to all files in Proxy seems to have fixed the issue - thanks Chip