baserow error on file column upload

[robi]

@nebulon the error points to the path below with a .pdf

[Errno 13] Permission denied: '/app/data/media/user_files/*.pdf

[midm]

@nebulon Yes there is a "file" column type on Baserow, to upload and store files. This is where I had this crash.

[robi]

@nebulon I can reproduce this on the demo instance.. when you create a new table, you get some default rows and columns, you then scroll right to add a new column, and choose file type, then try uploading any file. It will fail.

UPDATE:
The directories in /app/data/media are owned by root for some reason, chown -R to cloudron:cloudron does the trick.

Not sure why there is 62+MB of random images in user_files/, there's over a thousand files there!

Some images are back to root permissions after I did the chown to cloudron.

[nebulon]

Actually on a fresh install for me the uploads work just fine, also I can't quite see the permission issue. The start.sh has a chown -R cloudron:cloudron /app/data however as you indicated, something apparently changes ownership or creates files with root while the app is running.

Also all processes besides nginx are run as cloudron user https://git.cloudron.io/cloudron/baserow-app/-/blob/master/supervisor.conf

[robi]

@nebulon wow, not my experience at all with the demo instance.. it seemed like the baserow instance was doing things I didn't want it doing, like downloading 1000+ stock images (that's not what baserow is for!).

Did something nefarious sneak in there? You can inspect the app at https://brow.demo.cloudron.io/ (cloudron/cloudron)

It'd be nice to be able to see what all is running and changing permissions. Is there a way you can run execsnoop from startup?

Here's more info on execsnoop and how to log all processes being executed (it may not work with our new kernels though).

You can apparently follow a process using strace. If you know the PID of the process then you can do:

strace -o strace-<pid>.out -f -p <pid>

Notice the -f switch. It will help you to follow newly created processes that are descendants of the process whose PID was used in the command, above.

https://github.com/a2o/snoopy also seems to record process execution, aside from doing full audit process accounting (psacct).

[nebulon]

Hm really not sure how to reproduce this even in https://brow.demo.cloudron.io/database/13/table/70 (if that app instance still exists while others read this) I am able to upload files into the table just fine. PDFs as well as others, maybe something special about the file you try to upload?

[robi]

@nebulon that's because I fixed the permissions earlier, try a new instance and monitor the directory just as you chown

[girish]

I can confirm there is a whole bunch of files owned by root:

[girish]

I think the issue is that we do this sync_templates in the background:

echo "==> Syncing templates (in the background)"
/app/code/env/bin/python /app/code/backend/src/baserow/manage.py sync_templates &

And the above thing is also downloading a whole bunch of images from the web, not sure why.

[girish]

@robi said in baserow error on file column upload:

@nebulon wow, not my experience at all with the demo instance.. it seemed like the baserow instance was doing things I didn't want it doing, like downloading 1000+ stock images (that's not what baserow is for!).

Apparently, all those images are part of the "templates" - https://gitlab.com/bramw/baserow/-/tree/develop/backend/templates

[girish]

This is fixed in latest package.