I’m not the first one with this problem https://stackoverflow.com/questions/58128001/could-not-open-file-lol-json-permission-denied-using-jq where files I have permission to cat can’t be read by jq installed through snap. I have to pipe cat which is a bit rediculous.
This is on a fresh Ubuntu 20.04 install:
root@vultr:~# jq . ^C
root@vultr:~# echo {}
{}
root@vultr:~# echo {} > /tmp/aoeu
root@vultr:~# jq . /tmp/aoeu
jq: error: Could not open file /tmp/aoeu: No such file or directory
root@vultr:~#
root@vultr:~# cat /tmp/aoeu | jq .
{}
root@vultr:~# jq . /tmp/aoeu
jq: error: Could not open file /tmp/aoeu: No such file or directory
root@vultr:~# ls /tmp/
aoeu
firstboot.exec
firstboot.log
netplan_66406j60
snap.jq
systemd-private-2a44a9a87d2f43eb90cce931355f84dc-fwupd.service-1sThpg
systemd-private-2a44a9a87d2f43eb90cce931355f84dc-systemd-logind.service-3Qq9eh
systemd-private-2a44a9a87d2f43eb90cce931355f84dc-systemd-resolved.service-HRkRzg
systemd-private-2a44a9a87d2f43eb90cce931355f84dc-systemd-timesyncd.service-YTQVgi
root@vultr:~# jq --version
jq-1.5-1-a5b5cbe
root@vultr:~# echo {} > in-home-dir
root@vultr:~# jq . in-home-dir
jq: error: Could not open file in-home-dir: Permission denied
Strictly-confined snaps have independent /tmp directories. They do not use the system-provided /tmp. That means you cannot use /tmp to share files between snaps and the system.
It’s not clear here whether your root user’s home folder is /root or if you’ve got it on a different path. Also, you might have better luck using a regular user account with their home folder at /home/username.
you should be able to use /tmp/snap.jq/tmp instead though … (as root)
also you can always echo/cat and use a pipe:
$ echo '{"bar": "foo"}' | jq
{
"bar": "foo"
}
$ echo '{"bar": "foo"}' > foo.json
$ cat foo.json | jq
{
"bar": "foo"
}
$
It’s /root.
Can you please re-package jq with classic confinement so that it behaves like I expect a command line to tool to behave, instead of having its own permissions?
i did not package it and i refuse to create any classic snaps at all since i personally think they should not exist at all and are a broken design, but feel free to use the contact link on the snapcraft.io/jq page …
i do personally use the jq snap every day and havent felt limited by using a simple pipe though since i rarely ever use jq with actual files but typically parse something from other commands anyway …
2 Likes
I didn’t initially respond because you’re not going to change anything and because you do this for free (and I appreciate that!) and I can instantly get a complete refund from snapcraft at any time, without even asking, but I remember this thread from time to time in frustration and I just wanted to voice it.
This minor inconvenience is a price you are willing to pay for an ideological position that you accuired because you’ve spent a lot of time in the weeds thinking about whatever problem it is that snap packages solve. I just need to install software because I want to use it, I don’t care, it makes the “using software” part of my life harder, because we get a surprising, obviously wrong result "No such file or directory" and have to spend time searching around and learning about your ideology about how software (from authors I trust) doesn’t deserve to have access to certain directories on my computer to understand why it happens.
My whole frustration with this is that I (and every single person that wants to install a command line utility through snap) have to even know about it and have to spend time seeking out this knowledge. Just another arkane computer tidbit added to the pile… all because I wanted a command line tool to be updated automatically.
Is software telling me a file that exists doesn’t exist “good design”?
it probably isnt, no, but that would mean jq upstream would have to do something to show a more helpful error here …
in either case, jq does not qualify for classic, at least not for the reasons you mentioned in this thread … quoting from
Unsupported
- access to arbitrary files on the system because the
application isn’t designed with confinement in mind...
- access to arbitrary files on the system due to developer/user inertia
I’ve had a similar problem with /tmp before with users, and had to tell them to use the Flatpak version of a snap I’d packaged, because whilst Flatpak has the same default behaviour of private /tmp per package, it actually provides a way for the user to manually override this behaviour.
Speaking purely for desirability and not knowing what actually achieving it might require, I think their approach is more practical without sacrificing much for the end user. The majority of people might not notice it but those who do appreciate it being there. (And it extends beyond just mounts, Flatpak allows users to enable permissions that weren’t declared, Snap will not enable interfaces that are not declared.)
So sure, I agree accessing /tmp isn’t a good justification for classic, but having no way to access /tmp isn’t an ideal scenario either and it does come up as a pain point fairly regularly to the point I agree that it’d be nice if there was an option to treat it specially.
1 Like