0
Not a bug

Docker Container Reset, SQL Credentials and Files Exposed to WAN

it 1 week ago updated by jorgen 5 days ago 8

You can just imagine my shock this morning when I logged into my docker instance and found the setup wizard waiting for me.  I click next and it reveals my existing SQL database information (address, db name, user, password) for confirmation with the option to wipe all tables to continue.  Even though the wipe was optional the setup wizard was unable to proceed so I choose to wipe the database.  It then setup a new superuser account for me since the database was empty and permitted me to login.  Since I was able to wipe the database my 2FA was disabled and I had full access to all of my files.  The permissions aren't quite right as I seem to be able to add files to the instance but I cannot delete them.  This instance of FileRun was initially setup almost a year ago using the afian/filerun container and then was later upgraded it to the filerun/filerun container in the beginning of December.  I was able to login to the that instance after switching to the filerun/filerun container and encountered no issues in the following weeks so if this is the cause of the reset I would have expected it to happen after the initial switch between versions/maintainers. 


I am more bothered by the fact that the initial setup screen exposed my existing credentials (passed to the container as docker variables) and then permitted me to login to view all of my existing data with all of this being accessible over a WAN connection.  I would expect that if a system is going to fail that it should fail secure and that was not the case.  I am glad that I only use this instance to host ISO images and nothing sensitive.  

Answer

Answer
Not a bug

Yep, that will do it then - this was a docker template error that was published to unraid's community apps - this was a user error who put together the template, and not a filerun issue (Vlad is not to blame here on this one).

I noticed the problem right away and reached out to the user who submitted the template and they have fixed it - i just confirmed that the new version of the template is active now if you re-install it, it should have a volume mapping for /var/www/html as designed. 

As far as blowing away and seeing the same data, that my have happened if you simply restarted the container, but not actually recreated it (via removal and reinstall or via force update) -- again though this really isn't a FileRun issue because when it's used correctly this would never, ever happen. This was a template issue with unforeseen side-effects and was caused by incorrect docker template creation.

I spoke with the user who submitted the template just today and verified independently myself that the template is now fixed, so this shouldn't affect anyone anymore. 

To re-iterate, when installed and used correctly via the official filerun docker image and instructions from here: https://docs.filerun.com/docker there's just no way this could happen. 

That being said, current unraid template still does not include these variables below, I'm not sure if this impacts security of FileRun at all - but regardless, I would suggest adding them anyways because they're in the official documentation. 

I'll actually ping the author of the template again and ask him to add all of these as well ;) 

      APACHE_RUN_USER: www-data
      APACHE_RUN_USER_ID: 33
      APACHE_RUN_GROUP: www-data
      APACHE_RUN_GROUP_ID: 33
Under review

The Docker container does not start the FileRun installation wizard, unless there is no FileRun installation found at the mounted volume (/var/www/html).

So, please tell me, what else did you do, other than a "container reset"?

I am running in docker and I am not able to replicate this... Are you SURE you have your persistent volume mounted properly? -- The /var/www/html/ files must be persistent across docker "wipes" or recreations.

PS - If you're running on unraid, the template maintainer originally forgot to include the /var/ww/html/ volume, I alerted him to this and he has already pushed a fix to the template. 

If that volume is not mounted then your settings are not stored (Even tho your user data IS) and you could have just had auto-complete fields saved for your database info perhaps? 

I just tested wiping and refreshing my container multiple times, and I cannot recreate this at all. 

Vlad: The only thing I did was switch containers from afian/filerun to filerun/filerun back in December.  After the change I was able to login just fine using my existing credentials and 2FA.  I saw the new web interface for this version of FR.

CorneliousJD: Interesting about the /var/www/html mount.  The docker does not have a path specified for /var/www/html.  This was created from Unraid's Community Applications so is it possible that the /var/www/html was being stored in the docker image file instead.  The only path that was passed by docker was for /user-files which contains all of my data.  I passed a path through docker and that seems to have fixed the WebUI and it isn't going into the initial setup every time I reboot the docker (which I noticed it doing as I tested it today).  The credentials were not stored in autocomplete since I'm accessing the instance from a computer in my office which I would never use to configure it.  

Answer
Not a bug

Yep, that will do it then - this was a docker template error that was published to unraid's community apps - this was a user error who put together the template, and not a filerun issue (Vlad is not to blame here on this one).

I noticed the problem right away and reached out to the user who submitted the template and they have fixed it - i just confirmed that the new version of the template is active now if you re-install it, it should have a volume mapping for /var/www/html as designed. 

As far as blowing away and seeing the same data, that my have happened if you simply restarted the container, but not actually recreated it (via removal and reinstall or via force update) -- again though this really isn't a FileRun issue because when it's used correctly this would never, ever happen. This was a template issue with unforeseen side-effects and was caused by incorrect docker template creation.

I spoke with the user who submitted the template just today and verified independently myself that the template is now fixed, so this shouldn't affect anyone anymore. 

To re-iterate, when installed and used correctly via the official filerun docker image and instructions from here: https://docs.filerun.com/docker there's just no way this could happen. 

That being said, current unraid template still does not include these variables below, I'm not sure if this impacts security of FileRun at all - but regardless, I would suggest adding them anyways because they're in the official documentation. 

I'll actually ping the author of the template again and ask him to add all of these as well ;) 

      APACHE_RUN_USER: www-data
      APACHE_RUN_USER_ID: 33
      APACHE_RUN_GROUP: www-data
      APACHE_RUN_GROUP_ID: 33
+1

Thank you very much Cornelius for the information and your help getting the Unraid template fixed!

+1

Not a problem, I just started using FileRun via Docker on unraid myself and noticed the issue and wanted to get it sorted out with the user who uploaded it right away to prevent any issues like configs not being saved, etc, like what happened here. 


It should be good now, but @Vlad, do you know what impact the APACHE_RUN_USER/GROUP varaibles have on security? If they are missing, what is the downside? If needed I can do a PR on github for the template to make sure those get included for everyone else moving forward who uses FileRun via unraid!

I also confirmed today via some testing that the reason your SQL information was there is because that WAS in your docker container variable list in unraid, so the missing /var/www/html is what caused that to be shown, definitely wasn't autofill like I originally alluded to. 


It all boils down back to the missing volume mapping for /var/www/html/ 

This is noted in the officail documentation that it should be there, and was just a mixup on the unraid template, which is also now resolved, so you shouldn't have any other issues.

👍 Correct, the misconfiguration is corrected. Thanks