trampgeek / jobe

jobe is a server that runs small programming jobs in a variety of programming languages
MIT License
108 stars 78 forks source link

Making loaded files writable #58

Closed samul-1 closed 1 year ago

samul-1 commented 1 year ago

Hello,

I'm using Jobe as a code sandbox for my own LMS.

One change I'm trying to make is making files loaded in the workdir writable. I tried a few things but none worked.

First thing I tried: in LanguageTask.php, function prepare_execution_environment, I changed this line:

exec("setfacl -m u:{$this->user}:rwX {$this->workdir}")

to

 exec("setfacl -Rmd u:{$this->user}:rwX {$this->workdir}")

expecting that the rule would apply recursively to all files in the folder, including ones generated in the future. However, for some reason, what ends up happening is that I am not able to execute the executable file after compiling: for example, with a C task, I get

/usr/bin/ld: cannot open output file prog.c.exe: Permission denied
collect2: error: ld returned 1 exit status

Second thing I tried: in the function load_files in LanguageTask.php, after creating each file with file_put_contents, I added:

chown($destPath, $this->user)

However, this fails because it can only be used as root user, which is not the user under which Jobe runs.

How can I make the loaded files writable? Maybe I don't have a deep enough understanding of how Jobe works yet to find a solution, so any help is welcome.

trampgeek commented 1 year ago

Making uploaded files non-writeable was of course by design, for when using Jobe with Moodle CodeRunner. Even there, though, we occasionally want files to be writeable (e.g. with database questions, where the uploaded file is an sqlite3 database) and we achieve that simply by making a fresh copy of the original file for each test. A solution of that sort might be possible for you?

I wrote the Jobe code many years ago and can't immediately recall the details relating to FACLs. But perhaps the reason that your setfacl failed is that the -d flag removes all existing ACL entries, so that when the compile is attempted (which I think is still done by user www-data) the directory is no longer writeable by www-data? You might be able to fix that by adding another ACL to restore write access by www-data?

However, I recall that setting up the ACLs took quite a lot of thought, so I'd be reluctant to tinker with them myself. I think it would be cleaner to explicitly give jobe (or, better the specific jobe user) write access to each of the downloaded files, as you attempted with your chown approach. I think you can do that simply by prefixing the command with sudo. That should work as www-data is in the sudoers group (which it has to be in order to switch to the jobe user when running runguard. No guarantees, of course :)

Hope that helps. As I say, my memory of this is rather sketchy and I don't have time to work through it all again.

-- Richard