I'm not sorry. The change to Mint packages was the best thing I did to my
desktop in a long time.
This has saved me from so much frustration already.
A recipe that works: https://www.osso.nl/blog/chromium-browser-without-
ubuntu-snap-linux-mint/
Respectfully,
Walter
--
You received this bug no
Sorry but this should be marked "Won't fix" as per the Snapcraft team
response on #9.
** Changed in: chromium-browser (Ubuntu)
Assignee: Nathan Teodosio (nteodosio) => (unassigned)
** Changed in: chromium-browser (Ubuntu)
Status: Triaged => Won't Fix
--
You received this bug notific
** Changed in: chromium-browser (Ubuntu)
Status: Confirmed => Triaged
** Changed in: chromium-browser (Ubuntu)
Importance: Undecided => Low
** Changed in: chromium-browser (Ubuntu)
Assignee: (unassigned) => Nathan Teodosio (nteodosio)
--
You received this bug notification because
I have purged all of snap from my machines, so I cannot reproduce. But
I'm 100% positive Firefox suffers from exactly the same issues.
The snap team decided that apparmoring applications was the way forward,
even though this causes inexplicable breakage for some people who are
just trying to get w
I can also reproduce this issue in Firefox (stable channel, version
104.0.2-1), can you?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1987945
Title:
[snap] chromium does no
Thanks for the forward!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1987945
Title:
[snap] chromium does not read root-owned files in $HOME
Status in chromium-browser pack
> Yes, I will argue with you there.
Don't get me wrong, yours is a totally valid use case. I'm just saying
it's perhaps not that common, and perhaps doesn't justify the use of the
"read: all" attribute on the home interface, which would mean that the
interface wouldn't be auto-connected, which wou
Let's see what the snapd folks have to say about it:
https://forum.snapcraft.io/t/auto-connecting-the-home-interface-with-
read-all-for-a-browser-snap/31525
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https
There are precedents for this use case, apparently:
https://forum.snapcraft.io/t/interface-auto-connect-request-for-the-
universal-update-utility-snap-home-read-all/23125.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser i
Okay. So to unbreak the confinement in the mean time, one can do this:
(1) Find an include that is not owned by snap (because an update will
likely break things again):
# sed -e '/#include/!d;s/.*#include //' \
/var/lib/snapd/apparmor/profiles/snap.chromium.chromium |
sort -u
"Arguably"
Yes, I will argue with you there.
- How about tcpdump writing as the tcpdump user+group in my homedir? I
can read them, delete them, but not send them to someone using the
browser?
- Me getting files as root, because I need special powers (for vpn,
network, usb, ...)? mv(1)/cp(1) will
Arguably, the case for files not owned by the user in their home
directory is not very widespread.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1987945
Title:
[snap] chromi
12 matches
Mail list logo
