Should we ban use of 'freeroot' on PAWS?
Open, Needs TriagePublic

Description

Whenever I patrol the PAWS nfs server I see a lot of uses of 'freeroot.'

I have never used freeroot but as I understand it it's a way of installing a full OS into unprivileged userspace. Often when I see it it's alongside a full ubuntu24.qcow2 or similar OS image.

I tend to assume these are wrappers for miners or other CPU-stealing applications. In theory PAWS provides ready-made exec environments for common use cases. It's a little hard for me to imagine how you would write a useful notebook that includes a full bespoke execution environment... but maybe that's just a failure of my imagination?

I would like to enhance the scan-and-shrink script to find and destroy the contents of any directory named 'freeroot.' Will that also eliminate legit use-cases? And even if it's possible that it will, is it likely?

Related Objects

Event Timeline

I believe the historic use case for the bash shell access was running pywikibiot scripts. That should have no need to install a random VM. I would be fine with blocking/cleaning. We can always have discussions with users that feel they have a legit reason and maybe lead them into Toolforge or another environment if they can't fit well into PAWS.

Is the freeroot you are seeing @Andrew this https://github.com/foxytouxxx/freeroot project?

yes, at least in many cases.

find . -name README.md -exec grep "Foxytoux" {} \; | wc

3401   32322  244072

Change #1307855 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):

[operations/puppet@production] scan-and-shrink.py: add a very rough scoring system for user dirs

https://gerrit.wikimedia.org/r/1307855

Change #1307855 merged by Andrew Bogott:

[operations/puppet@production] scan-and-shrink.py: add a very rough scoring system for user dirs

https://gerrit.wikimedia.org/r/1307855

Change #1308135 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):

[operations/puppet@production] scan-and-shrink: raise deletion threshold score from 2 to 3

https://gerrit.wikimedia.org/r/1308135

Change #1308135 merged by Andrew Bogott:

[operations/puppet@production] scan-and-shrink: raise deletion threshold score from 2 to 3

https://gerrit.wikimedia.org/r/1308135

+1 for blocking first, and if anyone has a specific usecase to raise it and we can check what we can do

Change #1308157 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):

[operations/puppet@production] daily_file_cleanup: remove --dry-run

https://gerrit.wikimedia.org/r/1308157

Change #1308157 merged by Andrew Bogott:

[operations/puppet@production] daily_file_cleanup: remove --dry-run

https://gerrit.wikimedia.org/r/1308157

The current running code regards 'freeroot' as a strike against a notebook but not an automatic block. If that gets file usage under control then that may be good enough but I'll keep an eye on it.

Oh, also, to be clear: This is entirely a storage-based solution so far. Ideally we would be blocking and deleting users that cross the line but at the moment we're not doing anything to prevent users from re-creating their notebooks every 24 hours.