After playing around some days to get something “simple” working when done via a normal install (which is the current recommended way by using npm install --global pageres-cli), i finally got the following thing working, but i’m not sure if everything is correct as there are still some things shown in the audit log and some things i have the feeling are more like a workaround
using the pageres cli command for Nextcloud server to generate previews for the bookmarks app
let me describe what has been done:
i created the following pageres-cli/snapcraft.yaml at master · BigMichi1/pageres-cli (github.com)
what it does is, it installs all required npm modules and also downloads a headless chromium through puppeteer/puppeteer which caused some problems when the first versions of the snap should be released.
To avoid a manual approval everytime when a new version will be build i had to remove the nacl_* binaries, which from my point of view is OK because also the Chromium snap does not contain them.
The thing is that when i tried to add allow-sandbox: true to make chromium working with a sandbox, again the automatic approval failed. By reading in the forum the recommendation sometimes was to pass '--no-sandbox', '--disable-setuid-sandbox' and sometimes the recommandation was not to do it.
Is there any way to avoid the automatic approval and still allow the sandbox to be used?
I think this might be a common issue when somthing like puppeteer is used in an app which manages the chromium download.
still when i now Install pageres for Linux using the Snap Store | Snapcraft and running it, i get some warnings in the journalctl output. one is from node and another three are from chrome
kern.log:Jan 7 09:33:49 i7-4770 kernel: [346214.324085] audit: type=1326 audit(1610008429.136:612): auid=4294967295 uid=999 gid=999 ses=4294967295 pid=2390887 comm="node" exe="/snap/pageres/19/bin/node" sig=0 arch=c000003e syscall=92 compat=0 ip=0x7f804def94b7 code=0x50000
kern.log:Jan 7 09:33:49 i7-4770 kernel: [346214.362541] audit: type=1400 audit(1610008429.172:613): apparmor="DENIED" operation="open" profile="snap.pageres.pageres" name="/proc/2390982/mem" pid=2390982 comm="chrome" requested_mask="r" denied_mask="r" fsuid=999 ouid=999
kern.log:Jan 7 09:33:49 i7-4770 kernel: [346214.389909] audit: type=1400 audit(1610008429.200:614): apparmor="DENIED" operation="open" profile="snap.pageres.pageres" name="/proc/2390985/mem" pid=2390985 comm="chrome" requested_mask="r" denied_mask="r" fsuid=999 ouid=999
kern.log:Jan 7 09:33:49 i7-4770 kernel: [346214.390105] audit: type=1400 audit(1610008429.200:615): apparmor="DENIED" operation="open" profile="snap.pageres.pageres" name="/proc/2390984/mem" pid=2390984 comm="chrome" requested_mask="r" denied_mask="r" fsuid=999 ouid=999
as far as i can see and what i tested these warnings are not limiting the functionallity, but according to the snap documentation when building and publishing a snap all issues should be at least investigated. for the /proc/*/mem warning i only got the suggestion by using snappy-debug to adjust program to not access '@{PROC}/@{pid}/mem', but as it is downloaded by pupetteer there is no chance to adjust the code. maybe this is even not possible.
Can these warnings be ignored/silenced or is there anything that can be done when the snap is created?
So far no other problems except when the pageres command was executed by the web server user (the user that also runs the PHP process for Nextcloud). When calling the command a permission denied was issued saying that a folder snap/pageres/19 could not be created. So i created them manually, at least the snap folder then the others were created but the issue remained even if that folder was created. After poking around with the command I noticed that only users with a home directory in /home are working. The webserver user had a home directory in /var/www/.
So what i did is doing a bind mount of /var/www to /home/www via /etc/fstab
/var/www/ /home/www none defaults,bind 0 0
and changed the home directory for the webserver user in /etc/passws to use /home/www instead of /var/www
Now it was possible to run the command via the webserver user called in PHP
Doing this bind mount feels like a really diry hack to work around some security restrictions, is there anything that can be done to avoid this?
Having users not in /home is at least in my setups not everytime the case, especially when i need to deal with virtual users for my webservers.
Would be nice if someone can direct my in the correct direction to fix the above mentioned things related to my three questions.
Thanks in adcance