Cannot write in home directory

Hello! I try to copy a file in user home directory but i get EPERM error:


Snap connections:

Interface         Plug                              Slot               Notes
browser-support   test:browser-support   :browser-support   -
hardware-observe  test:hardware-observe  :hardware-observe  manual
home              test:home              :home              -
network           test:network           :network           -
network-bind      test:network-bind      :network-bind      -
opengl            test:opengl            :opengl            -
raw-usb           test:raw-usb           :raw-usb           manual
removable-media   test:removable-media   :removable-media   manual
wayland           test:wayland           :wayland           manual

Snapd version:

snap list
Name             Version        Rev    Tracking       Publisher   Notes
core18           20210309       1997   latest/stable  canonicalâś“  base
core20           20210319       975    latest/stable  canonicalâś“  base
lxd              4.0.6          20326  4.0/stable/…   canonical✓  -
mir-kiosk        2.3.2-snap117  6525   latest/stable  canonicalâś“  -
snapd            2.50           11841  latest/stable  canonicalâś“  snapd
test             0.1.0          x2     -              -           -

I have already seen this: Snap no longer has write permission - snapcraft - , but i have snapd 2.50 .

Any thoughts why this would happen?

1 Like

well, you are trying to write to /root … are you actually logged in as root (not running via sudo … ) or running the snap as daemon ?

The application is running as a daemon, it’s on the machine which should be live:

~$ snap services
Service                          Startup  Current   Notes
lxd.activate                     enabled  inactive  -
lxd.daemon                       enabled  inactive  socket-activated
mir-kiosk.daemon                 enabled  active    -
test.test                        enabled  active    -

and are you trying to copy at runtime or from some hook during i.e. and upgrade ?

At runtime, while electron browser window is running.

Also, i forgot to mention, this is on Ubuntu Server 20.04.

The wierd thing is that the electron app writes to log file, but when i need to copy env.json file:

fs.copyFileSync(App.storage_user__("env.json"), App.storage_user__("env.json.bak"))

it gives EPERM.

It seem the error appears only when i use copyFileSync.

There is no error when using: “renameSync”, “unlinkSync”.

are there any related seccomp errors in your journal ?

What should i grep exactly?

journalctl -f | grep DENIED perhaps … i assume you can not simply journalctl -f and have your daemon execute the copy stuff while watching the log in realtime ?

Luckily, i can.

This is the output:

May 17 10:01:30 machine audit[4099]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4099 comm="test" exe="/snap/test/x2/main/test" sig=0 arch=c000003e syscall=326 compat=0 ip=0x7f1fd1d1c639 code=0x50000
May 17 10:01:30 machine kernel: audit: type=1326 audit(1621245690.305:2086): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4099 comm="test" exe="/snap/test/x2/main/test" sig=0 arch=c000003e syscall=326 compat=0 ip=0x7f1fd1d1c639 code=0x50000

well, that looks definitely similar to what @mborzecki fixed in the other therad (assuming this is the same architecture, syscall numbers are architecture bound) … perhaps marcin has an idea here …

It runs on ubuntu server 20.04 lts.
Arch is:

uname -m

So… any news about this?

Both of those are copy_file_range. This call is permitted by the following:

# the file descriptors used here will already be mediated by apparmor,
# the 6th argument is flags, which currently is always 0
copy_file_range - - - - - 0

It might be that the fs.copyFileSync() call is using an unusual flags parameter in its usage of the syscall. The flags filtering was added in February 2021 in this commit.

1 Like

So there is no fix for it?

I’ve done some digging. It looks like NodeJS is calling everything correctly, so there shouldn’t be an issue here. Maybe someone from security can double check that the copy_file_range seccomp rule is working as expected.

1 Like

You might try stracing the snap that is failing for copy_file_range specifically with something like:

sudo snap run --strace='-f -ecopy_file_range' test.test

and see what arguments are being provided

Also what is the output of snap version ?

Snap version:

$ snap version
snap    2.50
snapd   2.50
series  16
ubuntu  20.04
kernel  5.4.0-73-generic

There is no output when the function “copyFileSync” is called, with any of:

sudo snap run --strace='-f -ecopy_file_range' test.test
sudo snap run --strace='-f -e copy_file_range' test.test

Is the snap published somewhere already so that I could try it locally?